Configuring an Internal Queue Listener

Reference: Internal Queue Listener Configuration Parameters

The following table lists and describes parameters for the Internal Queue listener.

Note: Parameters that are common to queue listeners are described in Listener Configuration Parameters.

Property

Description

Name of Internal Queue (required)

A simple, case-sensitive name used to tie the emitter and the listener. This name must be unique to the listener, but can be specified as the destination for any number of emitters.

Persistent

If enabled, messages are persisted. Persistent messages are held in the safestore until completion and can be recovered if the server is restarted.

Select one of the following options from the drop-down list:

none {false}

rdbms {rdbms}

file {true}

The rdbms option enables the application to persist messages to a remote database location where, in the event of a failover situation, a secondary server running remotely can continue processing persisted messages without any business interruption.

To use RDBMS persistence, you must create the iway_queues table in the JDBC provider, using the DDL script in the etc/setup directory. A hot backup channel can be configured to use the same RDBMS safestore.

Safestore Location

If persistent, this is the location in the file system to which documents are safestored.

Compress Persistent

If the queue is persistent, the documents written to the safestore can be compressed. Select one of the following options from the drop-down list:

smallest {best}

none {none}

fastest {speed}

standard {std}

The default option is to not compress (none).

Low Mark

If the size of the named queue falls below this value from above the value, the named listeners in the Control List are sent an activate message.

High Mark

If the size of the named queue goes above this value, a passivated message is sent to the listeners in the Control List.

Control List

If a high or low mark value is crossed, the appropriate message is sent to each listed listener. For example, if two listeners LISA and LISB are feeding the internal queue, listing them as LISA,LISB will cause each to receive the appropriate message.

Inhibit Add

If set, the queue will not accept new messages when its size reaches the high mark, and will resume accepting messages when the number of messages on the queue reaches the low mark. The effect of this inhibition can cascade through the application, controlling overall performance.

External Mark

When set to a number greater than 0, this causes the message to be stored in memory up to the specified number. When the queue grows larger than the specified number, the message is stored on disk. This is equivalent to splitting the memory and performance optimization for the messages in the queue, and is effective for large lists that may fill memory.

Support Pending

If set, messages can be pended for later execution if the process flow calls for a Fail/Pending operation. Pending messages persist for a specified time and are retried at a specific interval. You might use a pending operation in the event that a message cannot be processed because an external resource is currently unavailable.

Duration

Determines the length of time that a pended message can remain on the pending queue. The default is one day. You can use a duration specification, such as 1h for one hour. If the message cannot be processed during the duration, it is treated as a failed message.

Retry

Determines the interval (in seconds) between retrying pending requests. The default value is 600 seconds (10 minutes).

Property	Description
Name of Internal Queue (required)	A simple, case-sensitive name used to tie the emitter and the listener. This name must be unique to the listener, but can be specified as the destination for any number of emitters.
Persistent	If enabled, messages are persisted. Persistent messages are held in the safestore until completion and can be recovered if the server is restarted. Select one of the following options from the drop-down list: none {false} rdbms {rdbms} file {true} The rdbms option enables the application to persist messages to a remote database location where, in the event of a failover situation, a secondary server running remotely can continue processing persisted messages without any business interruption. To use RDBMS persistence, you must create the iway_queues table in the JDBC provider, using the DDL script in the etc/setup directory. A hot backup channel can be configured to use the same RDBMS safestore.
Safestore Location	If persistent, this is the location in the file system to which documents are safestored.
Compress Persistent	If the queue is persistent, the documents written to the safestore can be compressed. Select one of the following options from the drop-down list: smallest {best} none {none} fastest {speed} standard {std} The default option is to not compress (none).
Low Mark	If the size of the named queue falls below this value from above the value, the named listeners in the Control List are sent an activate message.
High Mark	If the size of the named queue goes above this value, a passivated message is sent to the listeners in the Control List.
Control List	If a high or low mark value is crossed, the appropriate message is sent to each listed listener. For example, if two listeners LISA and LISB are feeding the internal queue, listing them as LISA,LISB will cause each to receive the appropriate message.
Inhibit Add	If set, the queue will not accept new messages when its size reaches the high mark, and will resume accepting messages when the number of messages on the queue reaches the low mark. The effect of this inhibition can cascade through the application, controlling overall performance.
External Mark	When set to a number greater than 0, this causes the message to be stored in memory up to the specified number. When the queue grows larger than the specified number, the message is stored on disk. This is equivalent to splitting the memory and performance optimization for the messages in the queue, and is effective for large lists that may fill memory.
Support Pending	If set, messages can be pended for later execution if the process flow calls for a Fail/Pending operation. Pending messages persist for a specified time and are retried at a specific interval. You might use a pending operation in the event that a message cannot be processed because an external resource is currently unavailable.
Duration	Determines the length of time that a pended message can remain on the pending queue. The default is one day. You can use a duration specification, such as 1h for one hour. If the message cannot be processed during the duration, it is treated as a failed message.
Retry	Determines the interval (in seconds) between retrying pending requests. The default value is 600 seconds (10 minutes).

Note: Passivation and Inhibition affect the threading model and the movement of messages within an application. Using these facilities, performance can be improved by avoiding queue congestion. For more information on passivation and inhibition, see Chapter 1, Introducing iWay Service Manager in the iWay Service Manager User's Guide.

Reference: Internal Queue Listener Special Registers

The following table lists and describes the Special Registers (SREGs) available on the Internal Queue listener.

Name	Level	Type	Description
iwayconfig	System	String	The current active configuration name.
iwayhome	System	String	The base at which the server is loaded.
iwayworkdir	System	String	The path to the base of the current configuration.
msgsize	Document	Integer	The physical length of the message payload.
name	System	String	The assigned name of the master (listener).
protocol	System	String	The protocol on which message was received.
priority	Document	Integer	The priority of the incoming message.
tid	Document	String	Unique transaction ID.