JMSSender

FRAMES NO FRAMES

Overview

Package

Deprecated

Help

API Reference for EPL (ApamaDoc) 10.11.3.3

SUMMARY: IMPORT | CONSTANT | MEMBER | ACTION

DETAIL: IMPORT | CONSTANT | MEMBER | ACTION

com.apama.correlator.jms
Event JMSSender

An event object representing an existing JMS sender.

A JMS sender has an associated channel to which Apama events can be "sent", which will then be mapped to JMS messages using the requested message reliability setting and delivered to a destination on the JMS message bus.

Action summary
`string`	`getChannel()` Returns the Correlator channel to use for events that should be delivered to JMS using this sender.
`integer`	`getOutstandingEvents()` Returns the number of events that have been send to this sender's channel from the application, but are still queued waiting to be sent to JMS.
`string`	`getSenderId()` Returns the unique identifier of this sender.
`void`	`remove()` Requests removal of this JMS sender. The removal will be performed asynchronously, and completes after all events already sent by this context have been passed to JMS, and the associated JMS producer and session have been closed.
`integer`	`requestFlush()` Requests a notification event after flushing all messages already sent to the sender's channel by the current context.

Action detail

getChannel

            string getChannel()

Returns the Correlator channel to use for events that should be delivered to JMS using this sender.

Note that if this senderId does not exist or has been removed then events sent to this channel will be lost without a warning.

getOutstandingEvents

            integer getOutstandingEvents()

Returns the number of events that have been send to this sender's channel from the application, but are still queued waiting to be sent to JMS.

This allows an EPL application to throttle or reduce the rate at which it sends events based on the size of the backlog building up in the Correlator's queues, to ensure that the Correlator does not run out of memory due to a temporary peak in throughput rate or loss of the JMS connection.

Calling this action is a slightly expensive operation, so it is best to get the number of outstanding events once, then loop sending a batch of events. Therefore do not call getOutstandingEvents inside a loop that is continually sending events to JMS.

You must not call this method after calling remove().

getSenderId

            string getSenderId()

Returns the unique identifier of this sender.

remove

            void remove()

Requests removal of this JMS sender. The removal will be performed asynchronously, and completes after all events already sent by this context have been passed to JMS, and the associated JMS producer and session have been closed.

EPL applications may listen for the REMOVED JMSSenderStatus event to detect when the removal has completed.

If the connection is currently down there could be an unbounded delay in completing the removal of the sender. The application should not send any more events to the sender channel once this action has been called.

It is an error to attempt to remove a JMS sender that does not exist, or to attempt to remove a static JMS sender. Such errors will result in the termination of the current EPL monitor instance.

See Also:: com.apama.correlator.jms.JMSSenderStatus#REMOVED -

requestFlush

            integer requestFlush()

Requests a notification event after flushing all messages already sent to the sender's channel by the current context.

A JMSSenderFlushed event will be sent to this context when all the messages already sent to the sender channel have been processed and passed to the JMS broker (or dropped, in the case of non-recoverable mapping errors).

This feature is only applicable to BEST_EFFORT senders, as for AT_LEAST_ONCE/EXACTLY_ONCE senders reliability is already taken care of by the integration with Correlator state persistence. It is an error to call this action from a persistent monitor.

Applications may have multiple flush requests in flight at any one time. Performance will be improved by sending multiple messages (e.g. 1000) between each flush request.

Returns:: The unique request id for flush request, which will be included in the resulting JMSSenderFlushed event.

See Also:: com.apama.correlator.jms.JMSSenderFlushed - Notification event sent in response to