Package org.frankframework.jms

Class JmsListener

java.lang.Object
org.frankframework.jndi.JndiBase
org.frankframework.jms.JMSFacade
org.frankframework.jms.AbstractJmsListener
org.frankframework.jms.PushingJmsListener
org.frankframework.jms.JmsListener
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, ReceiverAware<jakarta.jms.Message>, org.springframework.beans.factory.Aware, org.springframework.context.ApplicationContextAware, org.springframework.context.Lifecycle
public class JmsListener extends PushingJmsListener
A true multi-threaded Listener-class.
Since version 4.1, Ibis supports distributed transactions using the XA-protocol. This feature is controlled by the transacted attribute. If this is set to true, received messages are committed or rolled back, possibly together with other actions, by the receiver or the pipeline. In case of a failure, all actions within the transaction are rolled back.

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, transacted should be used instead of listener.transacted.

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 for committing. 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, that in turn sends the message to whatever it is configured to.

You can add parameters to the JmsListener, the values will be added as Headers to the JMS response message.

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

Since:
4.0.1, since 4.8 as 'switch'-class
Author:
Gerrit van Brakel

  • Constructor Details

    • JmsListener

      public JmsListener()