Message listener container does not apply proper recovery anymore [SPR-12183]

[spring-projects-issues]

Stéphane Nicoll opened SPR-12183 and commented

There is this question on SO and also some other tests that confirm that 4.1 introduced a regression in the way the message listener container handles recovery.

It seems that certain exceptions are not being recognized the same way, not leading to an invalidation of the connection and therefore not applying the recovery at all.

It looks like #16400 may be the reason of the regression even though it's not obviously clear why it would be.

---

Affects: 4.1 GA

Issue Links:

• AMQP-427 BackOff support in SimpleMessageListenercontainer ("is depended on by")
• MessageListenerAdapter might throw JMSException on message deserialization [SPR-11778] #16400 MessageListenerAdapter might throw JMSException on message deserialization

Referenced from: commits bb45fb4

[spring-projects-issues]

Stéphane Nicoll commented

The regression was introduced by 6a04831. We have an extra trick to detect that we failed several times in a row that got removed. Actually this trick serves an additional purpose: if the listener fails to initialize, we would go in that removed if since the listener has not been called already and we faulty assume that it's the second time we're failing (while it's the first time, really).

There are probably a few things we could do here:

1. Track back why we implemented this logic and figure out if that's still valid. If that's not, that whole boolean flag should go away. If that is we have a problem as it does not play nicely with the backoff mechanism anymore. Maybe we need to restore the previous mechanism for that use case only?
2. Handle the initialization exception in a better way (i.e. if the listener hasn't even been called at all, maybe we should wrap that exception in such a way we can detect it and call a dedicated protected class which should give enough flexibility to figure out what to do. Right now we run a recovery (as we should) but that recovery works immediately as the broker is up. We should probably have some ways to manage that.

To be clear, the previous situation wasn't that better either: the app starts, we fail to connect to a certain queue, we wait X secs (5 by default) and we try again, it fails, etc. The only difference is that we've removed an extra if block that was applying the recovery timeout so now we're trying and failing in burst mode.

Users seem to rely on the feature if the broker starts at the same time as the app (it might fail one or two times and then the queue would eventually come up). This regression is therefore quite major.

[spring-projects-issues]

Stéphane Nicoll commented

As a safety precaution for 4.1.1, we have restored the sleep period interval that was wrongly removed. We can revisit the hook points in 4.2 if need to be.