Class PushingJmsListener

All Implemented Interfaces:
FrankElement, HasApplicationContext, HasName, HasPhysicalDestination, HasSender, IConfigurable, IKnowsDeliveryCount<jakarta.jms.Message>, IListener<jakarta.jms.Message>, IPortConnectedListener<jakarta.jms.Message>, IPushingListener<jakarta.jms.Message>, IRedeliveringListener<jakarta.jms.Message>, IScopeProvider, IThreadCountControllable, IWithParameters, IXAEnabled, NameAware, ConfigurableLifecycle, ReceiverAware<jakarta.jms.Message>, org.springframework.beans.factory.Aware, org.springframework.context.ApplicationContextAware, org.springframework.context.Lifecycle, org.springframework.context.Phased, org.springframework.context.SmartLifecycle
Direct Known Subclasses:
JmsListener

public class PushingJmsListener extends AbstractJmsListener implements IPortConnectedListener<jakarta.jms.Message>, IThreadCountControllable, IKnowsDeliveryCount<jakarta.jms.Message>
JMSListener re-implemented as a pushing listener rather than a pulling listener. The JMS messages have to come in from an external source: an MDB or a Spring message container.

This version of the JmsListener supports distributed transactions using the XA-protocol. No special action is required to have the listener join the transaction.

Setting listener.acknowledgeMode to "auto" means that messages are allways acknowledged (removed from the queue, regardless of what the status of the Adapter is. "client" means that the message will only be removed from the queue when the state of the Adapter equals the success state. The "dups" mode instructs the session to lazily acknowledge the delivery of the messages. This is likely to result in the delivery of duplicate messages if JMS fails. It should be used by consumers who are tolerant in processing duplicate messages. In cases where the client is tolerant of duplicate messages, some enhancement in performance can be achieved using this mode, since a session has lower overhead in trying to prevent duplicate messages.

The setting for listener.acknowledgeMode will only be processed if the setting for listener.transacted.

If useReplyTo is set and a replyTo-destination is specified in the message, the JmsListener sends the result of the processing in the pipeline to this destination. Otherwise the result is sent using the (optionally) specified Sender, that in turn sends the message to whatever it is configured to.

Notice: the JmsListener is ONLY capable of processing TextMessages and BytesMessage

Since:
4.8
Author:
Tim van der Leeuw