DefaultMessageListenerContainer does not log an error/warning when consumer tasks have been rejected #27451
Labels
in: messaging
Issues in messaging modules (jms, messaging)
status: backported
An issue that has been backported to maintenance branches
type: enhancement
A general enhancement
Milestone
Affects: 5.1.2, 5.3.9
Background: We experienced an issue due to
DefaultMessageListenerContainer
no longer receiving messages. This was because of a misunderstanding on our part howThreadPoolExecutorFactoryBean
works. We used following settings for the executor:corePoolSize=5
maximumPoolSize=10
queueCapacity=1
which was injected into a
DefaultMessageListenerContainer
with these parameters:concurrentConsumers=1
maxConcurrentConsumers=10
maxMessagesPerTask=1
The goal was to have a dynamic scaling of threads aligned with the scaling of consumers; however we shouldn't have set neither a queue capacity nor a maximum pool size and rather used something like
Executors.newCachedThreadPool()
; after all, the container will take care of not scheduling more than maxConcurrentConsumers * 2 threads in the worst case (since each task reschedules itself if all are busy).Our problem was reproducible given this test, the log is available here (I killed the process after no more messages were being received).
The issue: There are some rejected task debug level log entries due to the executor misconfiguration, but no warn or error entries. I would expect at least the error "All scheduled consumers have been paused, probably due to tasks having been rejected. Check your thread pool configuration! Manual recovery necessary through a start() call." at DefaultMessageListenerContainer.java#L1180-L1183 to appear. I don't understand why it didn't, since everything happens inside locks held on the
lifecycleMonitor
.On a side note, why is the rejection of tasks logged only at debug level (not even info)? After all, dropping below
concurrentConsumers
raises a warning (this works in the test if I setconcurrentConsumers
to 2). Is there any use case of configuring an executor that occasionally rejects tasks?The text was updated successfully, but these errors were encountered: