java.lang.Objectorg.springframework.jms.support.JmsAccessor
org.springframework.jms.support.destination.JmsDestinationAccessor
org.springframework.jms.listener.AbstractJmsListeningContainer
org.springframework.jms.listener.AbstractMessageListenerContainer
org.springframework.jms.listener.SimpleMessageListenerContainer
All Implemented Interfaces:
javax.jms.ExceptionListener, DisposableBean, BeanNameAware, Lifecycle, InitializingBean
Direct Known Subclasses:
SimpleMessageListenerContainer102
MessageConsumer.setMessageListener() method to
create concurrent MessageConsumers for the specified listeners.
NOTE: This class requires a JMS 1.1+ provider, because it builds on the domain-independent API. Use the SimpleMessageListenerContainer102 subclass for a JMS 1.0.2 provider, e.g. when running on a J2EE 1.3 server.
This is the simplest form of a message listener container. It creates a fixed number of JMS Sessions to invoke the listener, not allowing for dynamic adaptation to runtime demands. Its main advantage is its low level of complexity and the minimum requirements on the JMS provider: Not even the ServerSessionPool facility is required.
See the AbstractMessageListenerContainer javadoc for details on acknowledge modes and transaction options.
For a different style of MessageListener handling, through looped
MessageConsumer.receive() calls that also allow for
transactional reception of messages (registering them with XA transactions),
see DefaultMessageListenerContainer .
Juergen - Hoeller2.0 - | Fields inherited from org.springframework.jms.listener.AbstractJmsListeningContainer: |
|---|
| sharedConnectionMonitor, lifecycleMonitor |
| Fields inherited from org.springframework.jms.support.JmsAccessor: |
|---|
| logger |
| Method from org.springframework.jms.listener.SimpleMessageListenerContainer Summary: |
|---|
| createConsumer, createListenerConsumer, doInitialize, doShutdown, doStart, initializeConsumers, isPubSubNoLocal, onException, prepareSharedConnection, processMessage, setConcurrentConsumers, setPubSubNoLocal, setTaskExecutor, sharedConnectionEnabled, validateConfiguration |
| Methods from org.springframework.jms.listener.AbstractJmsListeningContainer: |
|---|
| afterPropertiesSet, createSharedConnection, destroy, doInitialize, doRescheduleTask, doShutdown, doStart, doStop, establishSharedConnection, getBeanName, getClientId, getPausedTaskCount, getSharedConnection, initialize, isActive, isRunning, logRejectedTask, prepareSharedConnection, refreshSharedConnection, rescheduleTaskIfNecessary, resumePausedTasks, runningAllowed, setAutoStartup, setBeanName, setClientId, sharedConnectionEnabled, shutdown, start, startSharedConnection, stop, stopSharedConnection, validateConfiguration, waitWhileNotRunning |
| Methods from org.springframework.jms.support.destination.JmsDestinationAccessor: |
|---|
| getDestinationResolver, isPubSubDomain, resolveDestinationName, setDestinationResolver, setPubSubDomain |
| Methods from org.springframework.jms.support.JmsAccessor: |
|---|
| afterPropertiesSet, convertJmsAccessException, createConnection, createSession, getConnectionFactory, getSessionAcknowledgeMode, isClientAcknowledge, isSessionTransacted, setConnectionFactory, setSessionAcknowledgeMode, setSessionAcknowledgeModeName, setSessionTransacted |
| Methods from java.lang.Object: |
|---|
| equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Method from org.springframework.jms.listener.SimpleMessageListenerContainer Detail: |
|---|
This implementation uses JMS 1.1 API. |
|
|
|
|
|
|
|
|
Executes the listener, exposing the current JMS Session as thread-bound resource (if "exposeListenerSession" is "true"). |
Raising the number of concurrent consumers is recommendable in order to scale the consumption of messages coming in from a queue. However, note that any ordering guarantees are lost once multiple consumers are registered. In general, stick with 1 consumer for low-volume queues. Do not raise the number of concurrent consumers for a topic. This would lead to concurrent consumption of the same message, which is hardly ever desirable. |
|
Default is none, that is, to run in the JMS provider's own receive thread, blocking the provider's receive endpoint while executing the listener. Specify a TaskExecutor for executing the listener in a different thread, rather than blocking the JMS provider, usually integrating with an existing thread pool. This allows to keep the number of concurrent consumers low (1) while still processing messages concurrently (decoupled from receiving!). NOTE: Specifying a TaskExecutor for listener execution affects acknowledgement semantics. Messages will then always get acknowledged before listener execution, with the underlying Session immediately reused for receiving the next message. Using this in combination with a transacted session or with client acknowledgement will lead to unspecified results! NOTE: Concurrent listener execution via a TaskExecutor will lead to concurrent processing of messages that have been received by the same underlying Session. As a consequence, it is not recommended to use this setting with a SessionAwareMessageListener , at least not if the latter performs actual work on the given Session. A standard javax.jms.MessageListener will work fine, in general. |
|
|