Package org.frankframework.jms

Class PushingJmsListener

java.lang.Object
org.frankframework.jndi.JndiBase
org.frankframework.jms.JMSFacade
org.frankframework.jms.JmsListenerBase
org.frankframework.jms.PushingJmsListener
All Implemented Interfaces:
HasPhysicalDestination, HasSender, IConfigurable, IConfigurationAware, IKnowsDeliveryCount<javax.jms.Message>, IListener<javax.jms.Message>, INamedObject, IPortConnectedListener<javax.jms.Message>, IPushingListener<javax.jms.Message>, IRedeliveringListener<javax.jms.Message>, IScopeProvider, IThreadCountControllable, IWithParameters, IXAEnabled, org.springframework.beans.factory.Aware, org.springframework.context.ApplicationContextAware
Direct Known Subclasses:
JmsListener
public class PushingJmsListener extends JmsListenerBase implements IPortConnectedListener<javax.jms.Message>, IThreadCountControllable, IKnowsDeliveryCount<javax.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.

Using jmsTransacted and acknowledgement
If jmsTransacted is set true, it should ensure that a message is received and processed on a both or nothing basis. IBIS will commit the the message, otherwise perform rollback. However, using jmsTransacted, IBIS does not bring transactions within the adapters under transaction control, compromising the idea of atomic transactions. In the roll-back situation messages sent to other destinations within the Pipeline are NOT rolled back if jmsTransacted is set true! In the failure situation the message is therefore completely processed, and the roll back does not mean that the processing is rolled back! To obtain the correct (transactional) behaviour, set transacted="true" for the enclosing Receiver. Do not use jmsTransacted for any new situation.

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 as well as for listener.jmsTransacted is false.

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