Back-off for DefaultMessageListenerContainer with OracleAQ has changed and is very short in SpringBoot 4

[andersnorgaard]

I think I have a problem that is somewhat similar to #36143 but slightly different, and still present in SpringBoot 4.0.6

I am running OracleAQ, and when I stop the queue (dequeue) in the database via SQL then the DefaultMessageListenerContainer logs warnings along the lines of

2026-05-15T14:14:20,911 [gChannel.container-390] WARN or.sp.jm.li.DefaultMessageListenerContainer - {} - Setup of JMS message listener invoker failed for destination 'G_QUEUE' - trying to recover. Cause: JMS-120: Dequeue failed. JDBC Connection Info:Instance: FREE(1), Session: (240.33763), Process ID: 5706, DB Name: FREE, DB UserId: 138, Service: freepdb1, Approx Start Time: Fri May 15 14:14:20 CEST 2026

On SpringBoot 3.5.8 the logs would appear roughly one per 5 seconds, while on 4.0.6 I get around 200 lines in 5 seconds. In the example above the thread-id had incremented to 390 in around 10 seconds.

The sql to disable dequeue is

BEGIN DBMS_AQADM.STOP_QUEUE (queue_name => 'G_QUEUE', enqueue => FALSE, dequeue => TRUE); END;

Do you also think that the 5-second interval is the intended behavior?

[andersnorgaard]

Here are some extra info from Claude that helped me look at the problem and alerted me to #36143

1. Thread-name churn confirms tasks are exiting per iteration
   Worth noting that with concurrency="1" on the JmsChannelFactoryBean, I'd expect exactly one invoker thread per channel. Instead, the SimpleAsyncTaskExecutor counter increments from 1 to 393 in 10 seconds with no thread name repeating. That means each AsyncMessageListenerInvoker task is running exactly once before exiting and being rescheduled — not just looping fast through executeOngoingLoop(). So whatever fix lands probably needs to address both the missing back-off and the fact that tasks are terminating after every failed receive when they ought to be staying alive and retrying in place.

2. Regression is not in the transactional path
   I originally had setTransactionManager(tm) and setSessionTransacted(true) set on the channel factory bean. I removed both (setSessionTransacted(false), no transaction manager) and the cadence did not change — still ~25 ms between WARN lines, still incrementing thread numbers without reuse. So the regression is in the common listener-setup-failure path, not in the transaction-template wrapping.

3. Spring Framework version
   For clarity: Spring Boot 4.0.6 pulls in Spring Framework 7.0.6. The behavior in this report is against 7.0.6 specifically.

4. Hypothesis: validateConnection doesn't catch AQ's failure mode
   I think the 7.0.4 fix from Back-off for DefaultMessageListenerContainer is not applied consistently in case of listener setup failure #36143 doesn't help here because of where Oracle AQ surfaces the failure. validateConnection opens a Session and calls createConsumer(destination) — but AQ allows both of those even when the queue has dequeue_enabled=NO. The rejection (JMS-120) only happens at the actual MessageConsumer.receive() call. So in the AQ case, refreshConnectionUntilSuccessful() completes without applying any back-off, and the loop re-enters receive() immediately, which fails again, repeat. Other providers where authentication or destination access fails earlier (like the Artemis bad-credentials reproducer in Back-off for DefaultMessageListenerContainer is not applied consistently in case of listener setup failure #36143) get caught by validateConnection; AQ-with-disabled-dequeue does not.

5. Comparison with the 6.2 code path
   For reference, in Spring Framework 6.2 the executeOngoingLoop() catch block in AsyncMessageListenerInvoker calls sleepBeforeRecoveryAttempt() near the top whenever lastMessageSucceeded is false. Its javadoc reads: "Apply the back off time once. In a regular scenario, the back off is only applied if we failed to recover with the broker. This additional sleep period avoids a burst retry scenario when the broker is actually up but something else is failing (i.e. listener specific)." That unconditional dwell is what produced the ~5-second cadence I see in production on Boot 3.5.8. In 7.x that path appears to have been reorganized so the back-off is driven only through refreshConnectionUntilSuccessful / validateConnection, which is provider-specific — and as point 4 describes, it doesn't fire for the AQ failure mode.