[JBMESSAGING-1367] Create JCA resource adapter for JBM 2.0

[jesper.pedersen]

The idea of this task is to replace the generic JMS resource adaptor currently used in JBoss Application Server with a resource adaptor that is specific to JBoss Messaging 2.0.

This will help in various ways:

1) Help with JBoss Messaging integration in various projects -- like JBoss Application Server
2) Provide a dedicated resource adaptor implementation that can expose JBoss Messaging specific features
3) Make the generic JMS adaptor an optional component in JBoss Application Server

An overview of the configuration options for the generic JMS adaptor can be found here: http://www.jboss.org/community/docs/DOC-9352 serving as a starting point for the discussion.
The code lives here: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/trunk/connector/src/main/org/jboss/resource/adapter/jms/

Take a look at the current source code to gather ideas of new features / how you would like things done differently in the specific resource adaptor - like removing the use of javax.jms.ConnectionConsumer.

Feel free to add sub-tasks to the holder issue for this work: https://jira.jboss.org/jira/browse/JBMESSAGING-1367

Based on your feedback I'll get some code up and running that we can import into the messaging SVN as a sub-project and take it from there.

[timfox]

Thanks Jesper-

The main thing is *no connection consumer*. Connection consumer was always a horrible abstraction and broken with respect to consumption in an XA transaction (See Mark Little's transaction book).

Clearly we need to support the JCA mandated config properties.

Regarding the ones currently used in the generic resource adapter:

user and password are still useful
max messages and max session - these can probably go
keepalive, reconnectinterval can go - JBM 2 handles its own automatic reconnection
deliveryactive - ok
All the dlq stuff can go - JBM has its own sophisticated dlq system

I'm thinking this is going to be relatively simple wrapper around the core API.

http://anonsvn.jboss.org/repos/messaging/trunk/src/main/org/jboss/messaging/core/client/

The core API is easy to understand if you've used JMS before. It's simpler than JMS.

Initially I'm thinking a 1-1 mapping between MDB instance and core session.

How about you start with a design proposal and we can develop from there...

[jesper.pedersen]

max messages and max session - these can probably go

These are used in the inflow part of the resource adaptor currently (in the class that implements javax.jms.ServerSessionPool).

All the dlq stuff can go - JBM has its own sophisticated dlq system

The DLQ functionality is also used in the inflow part - just for your information.

Thanks for the pointer to the internal API - I'll look it over and post some design.

I think we should aim for a solution that uses as much of the existing resource adaptor as possible for the first beta. After getting it up and running we can start to make optimizations.

[timfox]

"jesper.pedersen" wrote:

These are used in the inflow part of the resource adaptor currently (in the class that implements javax.jms.ServerSessionPool).

Can you take me through why that is necessary?

The DLQ functionality is also used in the inflow part - just for your information.

Hmmm, JBM already has DLQ I don't follow why this would be necessary for a JBM 2.0 only RA...

[timfox]

javax.jms.ServerSessionPool was part of the JMS ASF (application server facilities) monstrosity classes from the JMS spec.

Since we won't be using connection consumer, this should definitely not be necessary:

http://java.sun.com/javaee/5/docs/api/javax/jms/ServerSessionPool.html

[jesper.pedersen]

I'm not saying that implementing ServerSessionPool will be necessary for the JBM 2.0 resource adaptor.

The current adaptor has a pool of sessions for each activation

 <inbound-resourceadapter>
 <messageadapter>
 <messagelistener>
 <messagelistener-type>javax.jms.MessageListener</messagelistener-type>
 <activationspec>
 <activationspec-class>org.jboss.resource.adapter.jms.inflow.JmsActivationSpec</activationspec-class>
 <required-config-property>
 <config-property-name>destination</config-property-name>
 </required-config-property>
 </activationspec>
 </messagelistener>
 </messageadapter>
 </inbound-resourceadapter>

You can follow the flow JmsActivationSpec -> JmsActivation -> JmsServerSessionPool -> JmsServerSession (this class implements javax.jms.MessageListener).

I'm looking through your API currently and will post the initial design after big Turkey day holiday.

[jesper.pedersen]

Just a quick question - do I need to use the client.impl classes ?

ClientSessionFactory csf = new ClientSessionFactoryImpl(discoveryGroupName, discoveryGroupPort);

Or can I get an instance of the interface from somewhere ?

btw - DLQ handling will properly be mandatory in JCA 1.6 if an endpoint isn't available to the resource adaptor - so I keep the functionality around.

For now I have the classes in org.jboss.messaging.ra and sub-packages.

[timfox]

"jesper.pedersen" wrote:
Just a quick question - do I need to use the client.impl classes ?

ClientSessionFactory csf = new ClientSessionFactoryImpl(discoveryGroupName, discoveryGroupPort);

Or can I get an instance of the interface from somewhere ?

I'm not sure what you mean. That is an instance of the interface...

btw - DLQ handling will properly be mandatory in JCA 1.6 if an endpoint isn't available to the resource adaptor - so I keep the functionality around.

Can you explain a bit more what endpoint isn't available means?

For now I have the classes in org.jboss.messaging.ra and sub-packages.

ok

[jesper.pedersen]

I'm not sure what you mean. That is an instance of the interface...

Ok, so I need to pass discoveryGroupName and discoveryGroupPort in through the configuration.

Can you explain a bit more what endpoint isn't available means?

In this case it would be that a Message Driven Bean (endpoint) isn't available or failed to handle the incoming message.

 public void onMessage(Message message)
 {
 try
 {
 endpoint.beforeDelivery(JBMActivation.ONMESSAGE);

 try
 {
 if (dlqHandler == null
 || dlqHandler.handleRedeliveredMessage(message) == false)
 {
 MessageListener listener = (MessageListener) endpoint;
 listener.onMessage(message);
 }
 } finally
 {
 endpoint.afterDelivery();

 if (dlqHandler != null)
 dlqHandler.messageDelivered(message);
 }
 }

 catch (Throwable t)
 {
 log.error("Unexpected error delivering message " + message, t);

 if (txnStrategy != null)
 txnStrategy.error();
 }
 }

[timfox]

"jesper.pedersen" wrote:

I'm not sure what you mean. That is an instance of the interface...

Ok, so I need to pass discoveryGroupName and discoveryGroupPort in through the configuration.

There are several ways you can instantiate a session factory. One is by specifying a discovery address on which it can listen, or you can specify the server connection info straight out, or a list of servers and backup servers...

Take a look a the constructors on ClientSessionFactoryImpl - we probably need all the ClientSessionFactory attributes configurable via the JCA config.

Can you explain a bit more what endpoint isn't available means?

In this case it would be that a Message Driven Bean (endpoint) isn't available or failed to handle the incoming message.

I'm not sure I follow. This RA is for JBM 2 only, and JBM 2 always has DLQ functionality....

[timfox]

BTW I'll need to add you as a committer so you can commit in the JBM source tree.

Also, join us on IRC - that's where everything happens and everyone hangs out - it's much more efficient than forums.

[timfox]

Hi Jesper-

Any feedback?

[jesper.pedersen]

I'm in a meeting all week - I'll try and catch you next week on IRC...

[timfox]

I'm away from end of this week until January 16th.

We really need to get this done this week.

[jesper.pedersen]

So I'm working on this again...

I'm focusing on the outbound part of the adaptor first - which exposes the JMS 1.1 API.

Looking at ClientSessionFactoryImpl there are a lot of constructors - some with composite datatypes (such as TransportConfiguration) - so I think I'll focus on the

 public ClientSessionFactoryImpl(final String discoveryGroupName,
 final int discoveryGroupPort)
 throws Exception

first. We can add support for the others along the way.

FYI - configuration parameters to the resource adaptor are passed in through the ra.xml file - f.ex.

 <config-property>
 <description>The discovery group name</description>
 <config-property-name>DiscoveryGroupName</config-property-name>
 <config-property-type>java.lang.String</config-property-type>
 <config-property-value>myValue</config-property-value>
 </config-property>

Or is there a better way to initialize the client API and get a ClientSession ?