DefaultMessageListenerContainer
with SimpleMessageListenerContainer
I spotted that the second one ignores autoStartup
setting.Spring documentation states that
SimpleMessageListenerContainer
creates a fixed number of JMS sessions at startup and uses them throughout the lifespan of the container, but why this happens before checking the autoStartup
flag. I chose to explore source code for an answer.Initialization of MessageListenerContainers is done automatically when context starts up, as they implement the
Lifecycle
interface. It is worth to remember that lazy-init flag is ignored for lifecycle beans.Let’s look how the initialization flow looks like:
- constructor
- set properties (here auto start-up flag is set)
- post construct method – if defined
- doInitialize
- doStart
doStart
method depends on autoStartup
flag which is checked in DefaultLifecycleProcessor.startBeans
. Both containers use AbstractJmsListeningContainer’s doStart
implementation:
- default container doesn’t override it at all
- simple container executes it and after that initializes consumers
@Override protected void doStart() throws JMSException { super.doStart(); initializeConsumers(); }
doStart
establishes shared connection and resume all defined tasks. Default container task creates connection, session and consumer. Simple container doesn’t define any asynchronous tasks, instead it creates all these JMS components synchronously in its doInitialize
method. So consumers initialization in doStart
method is redundant in this case.Since Spring 3.1
SimpleMessageListenerContainer
has additional property connectLazily
,that can be used to skip initialization of JMS components in doInitialize
method. When this flag is set to true
and autoStartup
to false
, then message listener container needs to be started manually.
No comments:
Post a Comment