JMS Component Question

[fouquet.f]

Hi ,

I'm using Fuse ESB based on servicemix 3.4 last release

I've notice importante performance differency between the old jms end point and the new. The new seems to be very slower . Any explanation ?

Here is my xml files :

new :

     <jms:consumer service="damcap:PivotReceptionJMSConsume"

          endpoint="PivotReceptionJMSConsume"

          targetService="damcap:PojoIntegration"

          targetEndpoint="PojoIntegration"

          destinationName="queue/PivotReception"

          connectionFactory="#PivotReceptionConsumeconnectionFactory"

old :

          <jms:endpoint service="damcap:PivotReceptionJMSConsume"

          endpoint="PivotReceptionJMSConsume"

          targetService="damcap:PojoIntegration"

          targetEndpoint="PojoIntegration" role="consumer"

          destinationStyle="queue"

          jmsProviderDestinationName="queue/PivotReception"

          defaultMep="http://www.w3.org/2004/08/wsdl/in-only"

          defaultOperation="test:Echo" connectionFactory="#connectionFactory" />

[mielket]

Hello,

Do you have any details how you ran your performance test and what numbers you achieved?

If you have a unit test,  feel free to attach it here so that we can investigate.

[fouquet.f]

Thanks for your reply ,

For testing performance of JMS BC  I have a project who send 3000 msg on a JMS queue.

With the old JMS endpoint, the 3000 messages are send to a POJO in less than one minutes, average 10 seconds

With the new JMS endpoint the  transfert during more than 2 minutes .

I'm surprinsing by the performance, I think have a bad configuration .

Second point and perhaps an explanation I have problem when I want to activate the XA Transaction

Hier is my configuration for activate the XA transaction I throw an exception on the deployement .

( Message : Can't obtain a lock in the file )

Any idea ???

    &lt;jms:consumer service="damcap:PivotReceptionJMSConsume"

        endpoint="PivotReceptionJMSConsume"

        targetService="damcap:PojoIntegration"

        targetEndpoint="PojoIntegration"

        destinationName="queue/PivotReception"

        connectionFactory="#PivotReceptionConsumeconnectionFactory"

        transacted="xa"

        listenerType="server"

        serverSessionFactory="#PivotReceptionConsumepooledSessionFactory" /&gt;

    &lt;amqpool:xa-pool id="#PivotReceptionConsumeconnectionFactory" url="tcp://localhost:61616"

        maxConnections="8" transactionManager="#PivotReceptionConsumetransactionManager" /&gt;

    &lt;jencks:transactionManager id="PivotReceptionConsumetransactionManager"

        transactionLogDir="data/txlog" defaultTransactionTimeoutSeconds="600" /&gt;

    &lt;bean id="PivotReceptionConsumepooledSessionFactory"

        class="org.springframework.jms.listener.serversession.CommonsPoolServerSessionFactory" /&gt;

[mielket]

I created a quick testcase and at a first glance seem to observe the same behavior. Will need to investigate deeper.

[fouquet.f]

Hi ,

Thanks for your help,

I can't add some informations today, this is my example I use on a Queue

and I have very poor performance with or without XA transaction

I need the new jms endpoint for XA and JMS Topic durableSubscrition.

Some idea

[mielket]

The new jms endpoint component uses much of the Spring JMS implementation. Out of the box this endpoint is configured to use the Spring JMS DefaultMessageListenerContainer without any caching, which degrades performance.

You can either

1) configure caching for this DMLC

<jms:consumer service="damcap:PivotReceptionJMSConsume"
endpoint="PivotReceptionJMSConsume"
targetService="damcap:PojoIntegration"
targetEndpoint="PojoIntegration"
destinationName="queue/PivotReception"
connectionFactory="#PivotReceptionConsumeconnectionFactory" 
cacheLevel="3" />

2) or configure for a different Spring JMS listener

<jms:consumer service="damcap:PivotReceptionJMSConsume"
endpoint="PivotReceptionJMSConsume"
targetService="damcap:PojoIntegration"
targetEndpoint="PojoIntegration"
destinationName="queue/PivotReception"
connectionFactory="#PivotReceptionConsumeconnectionFactory" 
listenerType="server"/>

Both changes should boost performance and perform equally fast as the old JMS endpoint.

[mielket]

By the way, I've raised an Improvement request SM-1841. Not sure if the default configuration can be changed easily but it is worth discussing this option.

[fouquet.f]

Thanks a lot for your reply, it was exactly the reply to my problem

I have test both changes and added a SessionPool to my consumer

I have now good perf and I can activate XA transaction and DurableSubscrition

Perhaps it will interresting to add it to the documentation.

Other thinks for durable subscribtion it need the attribute Clientid to work , i think that it can be interesting added this to the doc too

ServiceMix and Fuse is definitly a good work