JEUS MQ Special Functions

This chapter describes the special functions of JEUS MQ, including message bridges, message sort, Global Order, message groups, message management, and topic multicast.

1. JEUS MQ Message Bridge

Message bridge is a function that connects two different MQs. The two different MQs can be classified into the following cases.

  • Different versions of the same MQ service (two different versions of JEUS MQs that are not compatible with each other)

  • Different MQ services (JEUS MQ and another vendor’s MQ such as WebLogic)

It is not recommended to configure a message bridge between the same versions of JEUS MQ services.

If you are using the same versions, it is safer and more efficient to connect a client to a remote destination. If a bridge between the same JEUS MQ service versions must be configured, to distinguish the bridge from general message services between the MQs, add the following option to the server’s execution script:

-Djeus.jms.client.use-single-server-entry=false

1.1. Server Configuration

The following two configurations are required to use a message bridge.

  • Configure two bridge connections for each end of a message bridge.

  • Configure the actual bridge entry that connects the two bridge connections.

Since Message Bridge operates separately from JEUS MQ, it is set under <resources> in domain.xml. The following is an example of setting up a bridge from JEUS 6’s MQ to Weblogic 10.3’s MQ.

domain.xml
<domain>
  ...
    <resource>
        <message-bridge>
            <bridge-connections>
                <connection>
                    <name>jeus6</name>
                    <classpath>file:///home/seunghoon/workspace/jeus6/lib/client/
    clientcontainer.jar</classpath>
                    <jndi-provider-url>127.0.0.1:19736</jndi-provider-url>
                    <jndi-initial-context-factory>jeus.jndi.JNSContextFactory
                    </jndi-initial-context-factory>
                    <connection-factory>XAQueueConnectionFactory</connection-factory>
                    <xa-support>false</xa-support>
                </connection>
                <connection>
                    <name>weblogic103</name>
                    <classpath>
                   file:///home/seunghoon/bea/wlserver_10.3/server/lib/wljmsclient.jar
                    </classpath>
                    <jndi-provider-url>t3://localhost:7001 </jndi-provider-url>
                    <jndi-initial-context-factory>
                   weblogic.jndi.WLInitialContextFactory</jndi-initial-context-factory>
                    <connection-factory>QueueConnectionFactory</connection-factory>
                    <xa-support>false</xa-support>
                </connection>
            </bridge-connections>
            <bridges>
                <bridge>
                    <name>bridge1</name>
                    <source>
                        <connection-name>jeus6</connection-name>
                        <destination>ExamplesQueue</destination>
                        <type>queue</type>
                    </source>
                    <target>
                        <connection-name>weblogic103</connection-name>
                        <destination>ExamplesQueue</destination>
                        <type>queue</type>
                    </target>
                </bridge>
            </bridges>
        </message-bridge>
    </resource>
</domain>

The following describes each configuration tag. All settings can be made under <message-bridge>.

  • <bridge-connection>

    Specifies a specific MQ to connect to.

    Tag Description

    <name>

    Specifies the name to represent the MQ.

    <classpath>

    Specifies the path to the JMS client library provided by the MQ.

    <jndi-provider-url>

    Specifies the Provider URL required when accessing the Naming Service where the Destination or ConnectionFactory of the corresponding MQ is registered.

    <jndi-initial-context-factory>

    Specifies the fully qualified name of the Initial Context Factory required when accessing the Naming Service where the Destination or Connection Factory of the corresponding MQ is registered.

    <connection-factory>

    Specifies the name of the Connection Factory to use when accessing the MQ.

    <xa-support>

    Specifies whether the MQ supports XA. Even if set to true, XA cannot be used if the Connection Factory itself does not support it.

  • <bridges><bridge>

    Specifies the connection (Bridge) between MQs set in <bridge-connection>. The child <bridge> tag indicates an individual bridge.

    Tag Description

    <name>

    Specifies the name of the bridge.

    <source>

    Indicates the MQ from which the Bridge will receive messages and the specific Destination of that MQ.

    • <connection-name>: Choose one of the names specified in <bridge-connection>.

    • <destination>: Set a specific destination for the MQ.

    • <type>: Set the type of the destination. Choose either queue or topic.

    <target>

    Specifies the MQ to which the Bridge will forward the received message and the specific Destination of that MQ. It is configured in the same way as the <source> setting.

2. JEUS MQ Message Sort

If there is a message producer but no consumer in a queue, or if there is a message consumer but the message reception is relatively slow, messages accumulate in the queue. When this happens, you can use a message sort function sort the queued messages according to key values that you define.

Messages can also be accumulated in a durable subscriber that is similar to a queue, and when this happens, you can use the message sort function. The key values include the basic JMS property values or property values that you define (User Property).

Message sorting is configured differently for servers and clients. To enable message sorting, servers are configured with domain.xml, while clients are configured with the message properties.

2.1. Server Configuration

To enable message sorting, a server has to be configured first. This message sorting configuration can be applied for a destination or durable subscription. For more information, refer to Destination Configuration and Durable Subscription Configuration.

The following is an example of setting the message sorting feature on the server.

domain.xml
<domain>
  ...
    <jms-engine>
        <message-sort>
            <name>example</name>
            <key>TEST</key>
            <type>Integer</type>
            <direction>ascending</direction>
        </message-sort>
    </jms-engine>

    <jms-resource>
        <destination>
            <type>queue</type>
            <name>ExamplesQueue</name>
            <message-sort>example</message-sort>
        </destination>
    </jms-resource>
</domain>

The <message-sort> tag specifies the property that will be the key value for sorting, the type of the property, and the sorting direction. And if you add the name of this <message-sort> to the destination or durable subscriber, the settings will be applied.

The following describes each child tag of <message-sort>.

Tag Description

<name>

Defines a name to represent the <message-sort> setting. Add this name to the <message-sort> setting of a queue or durable subscriber will to apply the setting.

<key>

Defines the name of the key that will be the basis for sorting.

<type>

Specifies the type of the key value. Choose one of Boolean, Byte, Float, Integer, Double, or String. (Default: String)

<direction>

Specifies the direction of sorting. Choose either ascending or descending.

The messages that do not correspond to the configured key value are not sorted, and the original order is maintained. This means that if there is a mixture of messages that correspond to and do not correspond to a key value in the queue, the former will be sorted in the configured order, and the latter will be kept in their original order.

2.2. Client Configuration

You can configure a key value that defines the Message Sorting property.

In the following example, the message sort key property is set to "TEST_KEY" that is used to sort messages.

Message msg = session.createTextMessage("Test");
msg.setIntProperty("TEST_KEY", 1);

3. JEUS MQ Global Order

Global Order ensures that the messages queued at the destination are delivered to a client exactly one at a time. In general, messages are processed simultaneously by multiple clients and there is no way to control the processing order of the messages. If multiple messages are sent in parallel, they are processed regardless of the order in which they are sent. Although this does not impact system performance, the global order function can be used to ensure the message processing order.

3.1. Client Setting

The client can use the Global Order API without additional configurations.

For a single message consumer, Global Order does not change the existing order. Hence, to use Global Order, multiple message consumers have to be configured for the destination.

In the following example, a message sender creates a Producer and casts the message to JeusMessageProducer, and then calls the Global Order API.

JeusMessageProducer producer = (JeusMessageProducer) session.createProducer(queue);
// Set global order and name
producer.startGlobalOrder("GLOBAL-ORDER-NAME");
// If name is not set
//producer.startGlobalOrder();

The GLOBAL-ORDER-NAME identifies the Global Order. If it is not configured, a random name is assigned. The Global Order name can be shared by multiple clients. If this function is used with clustering, the processing order is applied to the entire cluster.

4. JEUS MQ Message Group

Message group is a function that sends a group of messages that have the same purpose and are all queued at a destination to a single message consumer. For example, if 10 messages are set in a group, the messages are not delivered to the consumer until all 10 messages are in the queue.

This is similar to the transaction mechanism and can be used for similar purposes, and it can also be used with clustering.

4.1. Server Configuration

The following is an example of setting the message group feature on the server.

domain.xml
<domain>
  ...
    <jms-resource>
        <destination>
            <type>queue</type>
            <name>ExamplesQueue</name>
            <message-group>
                <message-handling>Pass</message-handling>
                <expiration-time>-1</expiration-time>
            </message-group>
        </destination>
    </jms-resource>
</domain>

The <message-group> tag defines the message group settings for a destination.

The following describes each child tag of <message-group>.

Tag Description

<message-handling>

Defines how the destination processes message groups. Choose either 'Pass' or 'Gather'. 'Pass' processes message groups the same way as individual messages. 'Gather' combines multiple messages in a group and delivers them as a single message.

<expiration-time>

Specifies the duration (in seconds) for which an incomplete message group can exist in the destination. The default value is -1, meaning it will not be destroyed until it is completed.

Make sure that you specify a value for 'Expiration Time'. Otherwise, an incomplete message group is created that is kept permanently in the server. This can cause unnecessary memory usage.

4.2. Client Configuration

In the client configuration, you must configure the message producer and message consumer settings.

  • Configuring the Message Producer

    To configure the message producer, use the message’s User Property.

    Message msg = session.createMessage();
// Message group name that represents the group.
msg.setStringProperty("JMS_JEUS_MSG_GROUP_NAME", "MESSAGE-GROUP-NAME");

// The order within the group, as well as the the priority number that determines the sequence for delivery to the client.
msg.setIntProperty("JMS_JEUS_MSG_GROUP_NUMBERING", 1);
producer.send(msg);

msg = session.createMessage();
msg.setStringProperty("JMS_JEUS_MSG_GROUP_NAME", "MESSAGE-GROUP-NAME");
msg.setIntProperty("JMS_JEUS_MSG_GROUP_NUMBERING", 2);
producer.send(msg);
. . .
msg = session.createMessage();
msg.setStringProperty("JMS_JEUS_MSG_GROUP_NAME", "MESSAGE-GROUP-NAME");
msg.setIntProperty("JMS_JEUS_MSG_GROUP_NUMBERING", 10);

// Last message of the group.
msg.setBooleanProperty("JMS_JEUS_MSG_GROUP_END", true);
producer.send(msg);

  • Configuring the Message Consumer

    The message consumer receives the message group as an ObjectMessage that contains the messages.

    // Messages within a message group is a single ObjectMessage, which is a list of the messages.
ObjectMessage result = (ObjectMessage) receiver.receive(TIME_OUT);
List list = (List) result.getObject();

int cnt = 1;
// Get one by one from the list as follows.
for(Object obj : list) {
    // Process messages by the order set in the message transmitter.
    TextMessage msg = (TextMessage) obj;
    . . .
}

5. JEUS MQ Message Management Functions

Message management functions are used to check, move, and delete messages that arrive at a destination while JEUS MQ messaging services are enabled.

The message management functions can be grouped into the following three categories.

Message monitoring and control are supported for the messages in a queue or durable subscription. Destination control is provided for the messages in the queues and topics.

5.1. Message Monitoring

With message monitoring functions, you can monitor messages in a queue or durable subscription and retrieve detailed message information.

Searching the Message List

You can monitor messages in a queue or durable subscription by selecting the ID, type, creation time, and other information. To search, delete, move, export, and perform other tasks, select a message from the list.

JMS messages are created and consumed quickly. If a message is searched for without enabling the Consumption Suspended setting in the Destination page, the search result may contain a message that has already been consumed.

Following are the steps for searching the message list.

  1. Different jeusadmin commands can be used depending on the location of the message to be searched.

    • Messages in a Queue

      For information about commands for querying the destination list, refer to list-jms-destinations in JEUS Reference Guide.

    • Messages in a Durable Subscription

      For information about commands for querying the durable subscription list, refer to list-jms-durable-subscriptions in JEUS Reference Guide.

  2. The message list in a Queue or Durable Subscription can be queried as well.

    You can look for a specific message in the message list by specifying the message ID, type, or creation time, or by using the message selector. To retrieve all messages in a Queue or Durable Subscription, enter the command with no parameter.

  3. From the list of messages, you can delete, move, or export a message. You can also see detailed information about the message.

Retrieving Detailed Message Information

The detailed information about messages in the Queues or Durable Subscriptions can be retrieved. It is possible to check the header information defined in JMS specification, message information, and configured properties.

JMS messages are created and consumed quickly. If a message is queried without enabling the Consumption Suspended setting for the Destination, the search result may contain a message that has already been consumed and thus no longer exists.

For information about commands for viewing message details, refer to view-jms-message in JEUS Reference Guide.

5.2. Message Control

jeusadmin provides control functions for managing incoming messages on the server, including moving, deleting, exporting, and importing messages.

Moving Messages

Messages can be moved to another destination on a server or cluster. This feature is useful for handling errors such as sending messages to a wrong destination.

  1. JMS messages are created and consumed quickly. If the messages are moved without enabling the Consumption Suspended setting in the Destination page, the search result may contain a message that has already been consumed.

  2. You can move messages to another destination. If a message at the target destination has the same ID as the one you moved, the new message overwrites the existing one. But if the existing message is already sent to a client while being overwritten, the message may not be synchronized between the client and the server. To avoid this problem, enable the Consumption Suspended setting before moving a message.

For information about commands for moving messages, refer to move-jms-messages in JEUS Reference Guide.

'All' option moves all messages in the current Queue or Durable subscriber to the specified Destination.

Deleting Messages

You can delete messages that are no longer needed.

JMS messages are created and consumed quickly. If the messages are deleted without enabling the Consumption Suspended setting in the Destination page, the search result may contain a message that has already been consumed. It is recommended to enable the Consumption Suspended setting before deleting a message.

For information about commands for deleting messages, refer to delete-jms-messages in JEUS Reference Guide.

To delete all messages in the current destination, use the All option.

Exporting Messages

The messages in a Queue or Durable Subscription can be exported to another server or cluster.

JMS messages are created and consumed quickly. If the messages are exported without enabling the Consumption Suspended setting in the Destination page, the search result may contain a message that has already been consumed. It is recommended to enable the Consumption Suspended setting before exporting a message.

For information about commands for exporting messages, refer to export-jms-messages in JEUS Reference Guide.

To export all messages in a destination or a durable subscription, use the 'All' option. As the result, messages are exported and then an xml file named 'messages.xml' will be downloaded through the browser.

Importing Messages

Messages can be imported to a destination as XML formatted data. An imported message is treated as a new message. Therefore, a new message ID is assigned to the message when it is imported to a destination.

If the 'Overwrite' checkbox is checked when importing messages, some messages that are overwritten may already have been delivered to the clients. In this case, messages are imported successfully but incorrectly overwritten. Hence, it is recommended to enable the Consumption Suspended setting before importing a message.

For information about commands for importing messages, refer to import-jms-messages in JEUS Reference Guide.

To overwrite an existing message at the destination that has the same message ID as the imported one, use the 'Overwrite' option. The message with the same message ID as the imported message will be overwritten.

5.3. Destination Monitoring

Using jeusadmin, you can monitor detailed information and statistics by destination as follows:

Item Description

Processed Messages

Messages processed by the destination.

Remaining Messages (current)

Messages currently remaining in the destination.

Remaining Messages (high mark)

The maximum number of messages remaining in the destination.

Pending Messages

Messages that have arrived at the destination successfully but have not yet been delivered to the receiver. You can search only when the Destination is a Queue.

Dispatched Messages

Messages that have been delivered from the destination to the receiver but have not received a response yet. You can search only when the Destination is a Queue.

Delivered Messages

Messages that have entered the destination and have been successfully delivered to the receiver.

Expired Messages

Messages that have entered the destination and have expired.

Moved Messages

Messages that have entered the destination and have been transferred to another destination. You can search only when the Destination is a Queue.

Removed Messages

Messages that have entered the destination and have been removed. You can search only when the Destination is a Queue.

Poisoned Messages

Messages that have entered the destination but were processed incorrectly.

Memory Usage (current)

The amount of memory currently used by the destination.

Memory Usage (high mark)

The maximum amount of memory that has been used by the destination.

5.4. Destination Control

Using jeusadmin, you can suspend or resume production and consumption services by destination.

Suspending or Resuming Message Production at a Destination

You can suspend or resume message production and consumption at a destination. When message production is suspended at a destination, you cannot create a message.

For information about commands for suspending and resuming production of the destination, refer to Destination Status Control in JEUS Reference Guide.

When a message is sent to a destination where message production has been suspended, the server waits for a specified time and throw a jeus.jms.common.destination.InvalidDestinationStateException through the ExceptionListener.
Suspending or Resuming Message Consumption at a Destination

You can suspend or resume message consumption at a destination. If you suspend message consumption is suspended at a destination, messages cannot be consumed at the destination.

For information about commands for suspending and resuming consumption of destinations, refer to Destination Status Control in JEUS Reference Guide.

When an attempt is made to consume a suspended message, the server operates as if there were no messages at the destination.

6. JEUS MQ Topic Multicast

Topic Multicast is a feature of transmitting messages from a topic to subscriber based on an IP multicast using User Datagram Protocol (UDP).

This provides significant performance advantages when using a pub/sub topic, but there may be a decrease in the reliability due to UDP for transmission.

This feature is available only in environments where IP multicast can be used. For testing whether the environment supports IP Multicast, refer to Creating a Domain that Uses Virtual Multicast in JEUS Domain Guide.

6.1. Server Configuration

Exchanging topic messages via IP Multicast requires two configurations. Firstly, the server and client must be configured to connect to the same multicase address. Secondly, the clients connected to the server must be configured to receive messages through Topic Multicast.

The multicast address is configured in the destination settings. By including the multicast address in the destination settings for topics, the client using that destination can receive messages through the same multicast address as the server without separate client configuration.

You can specify the way clients receive messages as Topic Multicast in the ConnectionFactory. To use the Topic Multicast feature, use the ConnectionFactory in which the Topic Multicast has been configured. If the Topic Multicast is not configured in the destination, messages can be received through the Transmission Control Protocol (TCP), which is the traditional method. Even if the Topic Multicast is set in a destination, messages are received through the TCP method if the Topic Multicast is not configured in the ConnectionFactory. When using durable subscriptions, a higher level of reliability is required compared to regular topic messages. Since one subscription delivers messages to only one client at a time, it does not support the Topic Multicast.

7. Reliable Message Transmission

In JEUS MQ, reliable message transmission is ensured by using a persistent store even in the case of a failure. A persistent store guarantees reliable message delivery between a JEUS MQ server and the message recipient. But it does not guarantee reliable message delivery when a message is sent to the server and when the server or the client fails.

To compensate for this limit, JEUS MQ provides a function to increase the reliability between the sender and the JEUS MQ server using a local persistent queue (hereafter LPQ) that is similar to the persistence store. LPQ saves data in the local storage and ensures that the stored data is processed normally. JEUS MQ saves messages using LPQ before they are sent and makes continuous attempts to send them until they are successfully sent to the server. Thus, LPQ increases reliability of the message transmission between the sender and the server.

Reliable message transmission using LPQ has the following characteristics.

  • Retransmitting messages until it succeeds regardless of the server status

  • Recovery of messages that failed to be sent due to abnormal client status

  • Asynchronous messaging

When the JMS client is sending a message, if the client is a Jakarta EE application that is deployed on the JMS server, which is the message recipient, the message is not sent over the network to improve performance. In this case, the LPQ configuration is ignored.

7.1. LPQ Activation

To use reliable messaging through LPQ, you must activate LPQ first. You need to create a storage to store messages, a queue for processing, and an object for managing the messages.

To execute a standalone client that uses LPQ, LPQ and storage libraries are additionally needed. The libraries are jeus-lpq-spi.jar, jeus-lpq.jar, jms-extentsion.jar, and jeus-store.jar, which are in the JEUS_HOME/lib/system directory.

To activate LPQ, choose one of the following ways:

  • Using the JVM option

    When a JEUS MQ client is executed, the JVM option is applied to activate LPQ as in the following. This option activates LPQ when JMS creates a connection in the client.

    -Djeus.jms.client.send-by-lpq-only=true

  • Using the LPQ configuration file

    When a JEUS MQ client is executed, LPQ is activated as it is configured by reading the file if the LPQ configuration file can be found in the designated path. For detailed information about the LPQ configuration file path and how to configure it, refer to LPQ Configuration.

  • Using the API for JEUS

    LPQ can be activated in the client source code by using the following API of JeusSession, a JEUS session object.

    public void startLPQ();

  1. The LPQ operation can be configured through the configuration file or system property when the JVM option or JEUS API is used. The default value is applied for unconfigured items. For detailed information about LPQ configuration, refer to LPQ Configuration.

  2. If JEUS API is not used, when LPQ will be activated is not specified. In this case, LPQ is activated when the JVM creates the first connection. LPQ terminates when the last connection is closed. However, if LPQ still has messages, it does not terminate until they have been processed.

7.2. LPQ Configuration

Once LPQ is activated, a message can be sent more reliably by using LPQ. There are four configuration units for sending messages through LPQ.

  • JVM Unit Configuration

    Used when LPQ is activated by using the JVM option. All messages from the JVM are sent through LPQ.

  • ConnectionFactory Unit Configuration

    When the Connection Factory names to use LPQ are added to the JVM option, all the messages that are sent from the connections created by the Connection Factory are sent through LPQ. Connection factory names are separately by a comma (,).

    jeus.jms.client.connection-factory-for-lpq=<ConnectionFactoryName1,ConnectionFactoryName2,..>

    JMS specifications do not have naming limits for connection factories. However, if a commas is used, the above option cannot be normally applied and the LPQ function cannot be used.

  • Session Unit Configuration

    Used to specify whether to send messages to each session by using LPQ. The following API of the JEUS message sender object can be used to send all messages that will be sent to the session by using LPQ.

    public void setLPQOnly(boolean lpqOnly);

  • Message Unit Configuration

    Used to specify whether to send each message through LPQ. Either use the following APIs of the JEUS message sender object, or configure the User Property of the message.

    // JEUS-dedicated API
public void sendWithLPQ(Message message);
public void sendWithLPQ(Message message, int deliveryMode, int priority, timeToLive);
public void sendWithLPQ(Destination destination, Message message);
public void sendWithLPQ(Destination destination, Message message, int deliveryMode, int priority, timeToLive);

// JMS message user property
Message msg = session.createMessage();
msg.setBooleanProperty("JMS_JEUS_USE_LPQ", true);

    LPQ activation by using JEUS API only enables LPQ to be used in the corresponding session. LPQ configuration for messages that are sent using other sessions is ignored.

7.3. LPQ Listener Configuration

When LPQ is used to send messages, the messages are processed asynchronously. Therefore, the client does not know whether a message has been sent or not. LPQ provides a listener to be able to get the message transmission time and result.

The following jeus.jms.LPQMessageListener interface is provided to get the message transmission result through the listener.

package jeus.jms;

public interface LPQForwardListener {
    /**
     * Event initiated when the message transfer is complete
     * @param message Transferred message
     */
    public void onComplete(Message message);

    /**
     * Event initiated when an exception occurs during message transfer
     * @param message Message being transferred
     * @param e Exception that occurred
     */
    public void onException(Message message, Exception e);

    /**
     * Event initiated when message transfer fails
     *
     * @param message Message that failed to be transferred
     * @param cause Cause of the failure
     */
    public void onFailure(Message message, Throwable cause);
}

You can retrieve the message transmission result by setting the implemented LPQMessageListener to the JeusSession object by using the following API.

public void setLPQMessageListener(jeus.jms.LPQMessageListener lpqMessageListener);

When using a JEUS object to activate LPQ, you can use the following API to both activate LPQ and set the listener.

public void startLPQ(jeus.jms.LPQMessageListener lpqMessageListener);

7.4. LPQ Configuration

LPQ Configurations include items for processing failed transmissions, operation during disconnection, and the storage size or location.

LPQ Configuration Items

The following describes LPQ configuration items.

  • Common Items

    Item Type Description

    jeus.lpq.name

    String

    LPQ name. (Default: JEUS_LPQ)

    jeus.lpq.max-message-count

    int

    Maximum number of messages that LPQ can process at a time. (Default: 819200)

    jeus.lpq.time-to-live

    long

    How long a message can remain in LPQ. (Default: 43200000ms (12 hours))

  • Transmission-Related Items

    Item Type Description

    jeus.lpq.retry-limit

    int

    Number of attempts to resend a failed message. If set to 0 or less, retries are attempted indefinitely.

    (Default: -1)

    jeus.lpq.retry-interval

    long

    Transmission interval for resending a message. (Default: 1000 ms)

    jeus.lpq.retry-interval-increment

    long

    Increment to increase the retry interval every time a message is resent. (Default: 0 ms)

  • Reconnection-related Items

    Item Type Description

    jeus.lpq.reconnect-retry-interval

    long

    Interval for reconnecting when the connection is lost.

    (Default: 5000 ms)

  • Storage-related Items

    Item Type Description

    jeus.lpq.store.store-mode

    int

    Storage type. Set to 1 to use the journal store and 2 to use the memory storage. (Default: 1)

    jeus.lpq.store.journal. store-base-dir

    String

    Name of the directory to create the Store in. The name must be unique per LPQ configuration and two or more concurrent connections are not allowed.

    If set to a relative path, it is set to a path under the directory where the configuration file exists or JVM is running.

    (Default: JEUS_LPQ_STORE)

    jeus.lpq.store.journal. initial-log-file-count

    int

    Number of log files to create initially when creating the Journal Store. (Default: 2)

    jeus.lpq.store.journal. max-log-file-count

    int

    Maximum number of log files to create.

    (Default: 10)

    jeus.lpq.store.journal. log-file-size

    String

    Log file size. (Default: 64 M)

    Append one of the following text after an integer value or number.

    • 'K'(KiloBytes)

    • 'M'(MegaBytes)

    • 'G'(GigaBytes)
How to Configure LPQ

The following describes how to configure LPQ. The order of configuration is runtime property configuration, the configuration file, and then the JVM option.

  • Configuration File

    When LPQ configuration file exists in the specified location, the configurations in the file are applied when LPQ is activated. Find the configuration file in order of DEPLOYED_HOME/myApp/WEB-INF/, DEPLOYED_HOME/myApp/META-INF/, and DEPLOYED_HOME/myApp/. The default value of the detailed configuration file path is 'jeus-lpq.properties' and can be changed using the following option.

    -Djeus.jms.client.lpq-configuration-path=jeus-lpq.properties

    The following is an example of the LPQ configuration file. The name of this example file is 'jeus-lpq.properties', and the file exists in 'JEUS_HOME/templates/lpq/'.

    #JEUS Local-Persistent-Queue Configuration
#[commons]
jeus.lpq.name=JEUS_LPQ
jeus.lpq.max-message-count=819200
jeus.lpq.time-to-live=43200000

#[forward]
jeus.lpq.retry-limit=-1
jeus.lpq.retry-interval=1000
jeus.lpq.retry-interval-increment=0

#[reconnect]
jeus.lpq.reconnect-retry-interval=5000

#[store]
jeus.lpq.store.store-mode=1

#[journal-store]
jeus.lpq.store.journal.store-base-dir=JEUS_LPQ
jeus.lpq.store.journal.max-log-file-count=10
jeus.lpq.store.journal.initial-log-file-count=2
jeus.lpq.store.journal.log-file-size=64M

  • System Property

    The previous configuration items can be set as system properties by using each item name as the key. For instance, if the LPQ name is configured, the JVM option can be configured when a JEUS MQ client is executed as in the following.

    -Djeus.lpq.name=<jeus lpq name>

    Runtime Configurations can be modified by changing the client source code.

    System.setProperty("jeus.lpq.name", <jeus lpq name>);