Skip to content

Better abstraction for transactional configuration in DMLC [SPR-7879] #12536

@spring-projects-issues

Description

@spring-projects-issues

Stéphane Nicoll opened SPR-7879 and commented

We experienced a threads leak using Spring's DMLC on JBoss 4.2.3. We configured our DMLC as follows:

<jms:listener-container
     destination-type="queue"
     concurrency="1"
     connection-factory="connectionFactory"
     destination-resolver="destinationResolver"
     transaction-manager="jmsTransactionManager"
     task-executor="jmsTaskExecutor">
  <jms:listener destination="queue/A" ref="defaultListener"/>
</jms:listener-container>

After some investigations and the help of the support we figured out that the following configuration helped fixing our threads leak issue

<jms:listener-container
     destination-type="queue"
     concurrency="1"
     connection-factory="connectionFactory"
     destination-resolver="destinationResolver"
     acknowledge="transacted"
     task-executor="jmsTaskExecutor">
  <jms:listener destination="queue/A" ref="defaultListener"/>
</jms:listener-container>

Our use case is that we have externalized basically the following:

  • The connection factory and destination resolver (in order to be able to connect to another 3rd party JMS broker)
  • The JmsTransactionManager, whether we want to enable XA support or not

In the first configuration, it's obvious it is easy to share the configuration of this listener container, just import a strategy that defines the 3 beans above and you're good (we have some kind of "profile" capability using naming conventions). The problem is that the second configuration is the only way to get a proper usage with JBoss (connection/threads leak).

I don't know how easy it would be but the JmsTrasanctionManager that I use is the following

<bean id="jmsTransactionManager" class="org.springframework.jms.connection.JmsTransactionManager">
    <property name="connectionFactory" ref="connectionFactory"/>
</bean>

Couldn't we imagine a solution where the DMLC is smart enough to look at the transaction manager type and flip to the "acknowledge=transacted" mode? I understand the JMS API is related to the issue but reading the doc, it's hard to understand what would be the impact of each option.


Affects: 3.0.5

Issue Links:

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions