DefaultMessageListenerContainer fails to reconnect to ActiveMQ broker

[yihuliejiu]

Affects: <Spring Framework version>
5.2.25

First, a little background：
For a variety of reasons, we discovered the issue after upgrading the spring upgrade from 3.0.7 to 5.2.25.

My puzzle scenario is as follows:
Found in our tests

1. A client connects to ActiveMQ
2. The ActiveMQ service stopped abnormally and was restored after about 5 minutes
3. After recovery, the default message listener log displays the following information:
   DefaultMessageListenerContainer - Could not refresh JMS Connection for destination 'xxx' - retrying using FixedBackOff{interval=5000, currentAttempts=20, maxAttempts=unlimited}. Cause: The JMS connection has failed: java.io.EOFException
4. After this, the client reconnects N times, but still fails

After investigation, we learned that

Spring's 5.2.25 version，org.springframework.jms.connection.SingleConnectionFactory.initConnection() for the connection of assignment problem，org.springframework.jms.listener.DefaultMessageListenerContainer.refreshConnectionUntilSuccessful() can't get out of the while loop because an exception in org.springframework.jms.connection.SingleConnectionFactory.prepareConnection(Connection) causes the connection to become non-null, causes org.springframework.jms.connection.SingleConnectionFactory.getConnection() to not get a new link, and causes org.springframework.jms.listener.DefaultMessageListenerContainer.refreshConnectionUntilSuccessful() to not get out of the while loop

One more question:
The problem is very similar to this problem,
DefaultMessageListenerContainer fails to reconnect to ActiveMQ broker #23058
But #23058 was fixed as early as 2019, and spring 5.2.25 is the version released in July 2023, why this issue is not fixed in version 5.2.25, which makes me confused

（My English is very poor. I hope you can understand it）

Sorry, github is infrequent and may not be able to see and respond to your messages in a timely manner
You can contact me by email. Thank you
my email: echo.t1@qq.com

ActiveMQ version:5.5.1
jms version:5.2.25

[snicoll]

After investigation, we learned that

You shouldn't be using SingleConnectionFactory with DefaultMessageListenerContainer. Why don't you set the ActiveMQConnectionFactory directly? Can you try that and report if that problem persists?

[yihuliejiu]

Thank you very much for your time
But，Set the ActiveMQConnectionFactory directly? I'm sorry, I'm not quite sure what you mean

[yihuliejiu]

My temporary solution to the above problem:
In spring-jms5.2.25.jar,Change spring's 5.2.25 version SingleConnectionFactory#initConnection() to spring's main branch latest code SingleConnectionFactory#initConnection()

After today's verification test, this can solve my problem

[yihuliejiu]

1.This is the implementation of 5.2.25.

spring-framework/spring-jms/src/main/java/org/springframework/jms/connection/SingleConnectionFactory.java

Line 340 in 4fd7c19

public void initConnection() throws JMSException {

2.This is the implementation of the spring-jms's main branch.

spring-framework/spring-jms/src/main/java/org/springframework/jms/connection/SingleConnectionFactory.java

Line 402 in 37c2619

public void initConnection() throws JMSException {

The handling of prepareConnection(con) in initConnection() is different, which is why I think this may be the key to the problem

One has a try-catch and the other doesn't have a try-catch

[yihuliejiu]

I just found out that it's very similar to this problem，My situation is pretty much the same
#29115 (comment)

[yihuliejiu]

About using SingleConnectionFactory and DefaultMessageListenerContainer, I did not intentionally configuration, I only in the XML configuration ActiveMQConnectionFactory and SingleConnectionFactory, So they (SingleConnectionFactory and DefaultMessageListenerContainer) is the default combination??

[snicoll]

Please upgrade to 5.3.26 or later as the issue you've referenced has been backported. AnActiveMQConnectionFactory and SingleConnectionFactory are both ConnectionFactory implementations so you don't need the latter.