Where is OSGi JMS pooled ConnectionFactory in Fuse ESB v7.x ?

[alstsever_alain.saint-sever]

Hi,

In previous ESB releases a JMS pooled connection factory was exported as an OSGi Service in etc/activemq-broker.xml file.

With the ESB Enterprise releases, the file etc/activemq.xml does not contain any OSGi Service declaration nor Connection Factory. It happens that a simple, non-pooled, connection factory is exported in the OSGi registry by the Fuse MQ Fabric bundle (bundle which make use of both activemq.xml and org.fusesource.mq.fabric.server-default.cfg files to create a broker).

The problem is: this connection factory is not wrapped into a PooledConnectionFactory.

I don't want to modify all my existing bundles to add all the pool connection beans and settings: I want this pooled connection factory to be declared once (same as in "old" ESB releases).

The enterprise documentations of Fuse ESB or Fuse MQ never mention how to deal with a JMS pool.

What is the best way to achieve this?

Thanks.

[garytully]

The best way would be to define a pooled connection factory service in a blueprint xml file and drop it into the deploy directory. Essentially what activemq-broker.xml did but without the broker.

Something like:

<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
           xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0"
           xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0"
           xmlns:amq="http://activemq.apache.org/schema/core">

    <!-- Allows us to use system properties as variables in this configuration file -->
    <ext:property-placeholder></ext:property-placeholder>

    <bean id="activemqConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL" value="tcp://0.0.0.0:61616"></property>
    </bean>

    <bean id="pooledConnectionFactory" class="org.apache.activemq.pool.PooledConnectionFactory">
        <property name="maxConnections" value="8"></property>
        <property name="connectionFactory" ref="activemqConnectionFactory"></property>
    </bean>

    <bean id="resourceManager" class="org.apache.activemq.pool.ActiveMQResourceManager" init-method="recoverResource">
          <property name="transactionManager" ref="transactionManager"></property>
          <property name="connectionFactory" ref="activemqConnectionFactory"></property>
          <property name="resourceName" value="activemq.${name}"></property>
    </bean>

    <reference id="transactionManager" interface="javax.transaction.TransactionManager"></reference>

    <service ref="pooledConnectionFactory" interface="javax.jms.ConnectionFactory">
        <service-properties>
            <entry key="name" value="localhost"></entry>
        </service-properties>
    </service>

</blueprint>

[alstsever_alain.saint-sever]

Hi Gary,

Thanks. I saw you proposed something similar in issue http://fusesource.com/issues/browse/ENTMQ-36. It is even better in fact since you first start by getting the existing JMS Connection Factory exposed as an OSGi Service before wrapping it into a pooled connection factory. I definitely don't want to deal with a broker url in both activemq.xml and the new blueprint xml file with the pool declaration. Si I think I will proceed this way.

Only "problem" with this solution: I will end up with 2 javax.jms.ConnectionFactory OSGi services so I will have to update my bundles to add a filter to pick the pooled connection factory. Not that great. I would have prefered to be able to directly enable and expose a pooled connection factory service by adding dedicated properties (pool settings, pool factory...) in the org.fusesource.mq.fabric.server-default.cfg file. May be an interesting feature no?

Thanks.

[garytully]

very true, if you want a vm connection factory then best to reuse the one provided/registered by mq-fabric. ie (org.fusesource.mq.fabric.server-*.cfg)

It uses a name attribute with the value of the brokerName so that it is easy to filter.

Note you can disable the service registration via the property: registerService=false so that you don't get two factories registered.

The thinking is that a vm factory is simple and useful for demos etc, but the applications may want to configure their own pooled connection factory settings, transaction managers, broker url etc... so it is best to externalize this from the broker configuration.