Chapter 8 Setting up the Message Service
Once you have configured the message service, you can perform all administrative tasks using the CtsComponents::MessageService CORBA API--see Chapter 29, "Using the Message Service," in the EAServer Programmer's Guide for more information. You can also use Jaguar Manager to add and configure the message service parts:
To provide permanent destinations for JMS client applications, define message queues and message topics using Jaguar Manager. When you create a permanent destination, you can optimize its configuration properties, which benefits every JMS client application that uses the destination. Message queues and topics are both called message consumers.
Adding a message queue
Configuring a message queue's properties
Property | Datatype | Default value | Description |
---|---|---|---|
REQUIRES_ACKNOWLEDGE | boolean | false | Set to true to guarantee that each persistent message is delivered at least once. Transient messages may be lost if a server fails. |
REQUIRES_TRANSACTION | boolean | false | Set to true to guarantee that a persistent message is delivered only once, which means that only one transaction can receive the message and successfully commit. |
IGNORE_DUPLICATE_KEY | boolean | false | Set to true to avoid duplicate messages when the message producer sends a message outside a transaction or forwards a message from a remote system. You can use this option with the CORBA API, where you can specify the message key before producing a message. |
table | string | "none" | To save the queue's messages in a database table other than message_queue, enter the table name. |
maximum | long | 0 | The maximum number of messages held in memory
for an active queue; if set to zero or a negative number, there
is no limit. When the limit is reached, messages are discarded in
the order that they would have been retrieved.
If a persistent message is discarded from memory, you can still retrieve it from the database. Transient messages are not stored in the database, so if they are discarded from memory, they are lost. |
timeout | long | 0 | The number of seconds the queue remains in memory when it is not being accessed by a client and it has no registered listener; set to zero or a negative number for no timeout. Any transient messages that are in memory when a timeout occurs are discarded. |
share | boolean | true | Indicates whether multiple clients can simultaneously receive messages from the queue. When a queue is not shared, only one client at a time can receive messages from it. If other clients try to receive a message, they get an OBJECT_NOT_EXIST system exception. |
store | boolean | true | Indicates whether to store replicated transient messages that are added to the queue. To avoid duplicate message processing within a cluster where a shared queue may reside in memory on multiple servers, set to true. |
qop | string | "none" | Indicates the quality of protection required for the message queue object. |
Deactivating
a message queue
Deleting all the messages in a queue
Deleting a message queue
Adding
a topic
Configuring a topic
Property | Datatype | Default value | Description |
---|---|---|---|
timeout | long | 0 | Indicates the number of seconds the topic remains in memory when no active queues have selectors registered for the topic; set to zero or a negative number for no time out. Topics with no timeout are activated at server start-up. |
Deleting a topic
The message service includes a message queue and a thread
pool called "<system>" for tasks
that require internal messaging, such as synchronizing a cluster.
The <system> message queue and thread pool are
visible in Jaguar Manager and as output from some jagtool commands.
To enable JMS applications to establish connections with the message service, create queue connection factories for PTP messaging, and create topic connection factories for Pub/Sub messaging.
Adding a queue or topic connection factory
Configuring a connection factory's properties
Property | Datatype | Default value | Description |
---|---|---|---|
CLIENT_ID | string | blank | Used for topic connection factories only. It enables EAServer to uniquely identify a client if it disconnects and later reconnects. Every connection that is created using this connection factory inherits this ID. The CLIENT_ID is ignored for queue connections. |
CONFIG_QUEUE | string | blank | When you access a queue or topic, its configuration properties are copied from this named queue. |
THREAD_POOL | string | blank | The message service uses threads from this thread pool for client notification. Using a thread pool can significantly improve performance. |
IGNORE_DUPLICATE_KEY | boolean | true | Indicates whether a message should be ignored if it is a duplicate. |
NO_IMPLICIT_CREATION | boolean | true | Indicates whether a queue or topic that does not already exist should be implicitly created when a client attempts to access it. |
REQUIRES_ACKNOWLEDGE | boolean | false | To optimize the performance of a JMS application, set to false. In this case, the message service does not acknowledge messages. If a connection terminates unexpectedly, messages may be lost. |
REQUIRES_TRANSACTION | boolean | true | To force the methods publish, send, receive,
and onMessage to participate in transactions,
set to true. To improve throughput for bulk publishing, sending,
or receiving transient messages, set to false.
For information about using transactions, see Chapter 2, "Understanding Transactions and Component Lifecycles," in the EAServer Programmer's Guide. |
SHARED_LISTENER | boolean | false | When set to true, all message consumers
for a connection use the same message listener.
A shared listener can greatly improve performance for nondurable topic subscribers by creating a single message queue for all the topic subscriptions. To use this feature, install a message listener on the first topic subscription, then each nondurable subscription that uses the connection, receives messages from this listener. EAServer imposes two restrictions for shared listeners:
|
SUPPORTS_TRANSACTION | boolean | true | Determines whether JMS publish, send, receive,
and onMessage calls use the SUPPORTS_TRANSACTION
option.
If you set this to false, it significantly improves throughput for transient message bulk processing. |
TRANSPARENT_FAILOVER | boolean | true | Indicates whether JMS clients should allow transparent failover for message service operations. If set to false, a pinned object is used. If set to true, carefully consider the IGNORE_DUPLICATE_KEY setting. |
To filter the messages you receive and to subscribe to specific message topics, add message selectors. You can add as many selectors as you want to each message queue.
Adding
a message selector
StockPrice.SY
Deleting a message selector
To provide asynchronous message notification, implement and install a message listener on a message queue. A message listener can be either:
For information on how to implement, install, and configure an MDB, see Chapter 29, "Using the Message Service," in the EAServer Programmer's Guide.
Installing an EAServer message listener
Before you install the message listener component, configure it to support the MessageListener interface.
Configuring a component to support the CtsComponents::MessageListener
interface
Alternately, you can use the IDL editor and modify your component's existing interface to inherit from CtsComponents::MessageListener; for example:
module msglistener { interface Receiver : ::CtsComponents::MessageListener { ... } };
Deleting an EAServer message listener
To control access to a message queue or topic, add one or more access roles. If more than one access role is assigned to a message consumer, a client needs to possess only one of the roles to access the queue or topic. If a message consumer has no assigned roles, any client can access it.
Adding an access
role
Message consumer | Folder title |
---|---|
Active queue | Active Queues |
Inactive queue | Configured Queues |
Active topic | Active Topics |
Inactive topic | Configured Topics |
Deleting an access role from a message queue or
topic
Message consumer | Folder title |
---|---|
Active queue | Active Queues |
Inactive queue | Configured Queues |
Active topic | Active Topics |
Inactive topic | Configured Topics |
To provide asynchronous client and component notification, define thread pools and specify the number of threads dedicated to each type of notification.
Adding a thread pool
Reader, writer, and worker threads To use a thread pool for client notification, set the value of readers to "3", writers to "2", and workers to "0". Based on your own performance measurements, increase the number of reader and writer threads if it improves throughput. Using thread pools to improve performance is generally suitable only for high-volume client notification with transient messages. When message delivery is transactional or IIOP/SSL via the QOP property, the thread pool's reader and writer threads are not used.
To use a thread pool for component notification, set the values of both readers and writers to "0". Set the value of workers to "1" unless you want to allow parallel message processing, in which case you would increase this value. Modifying the number of threads in a thread pool
Property | Datatype | Default value | Description |
---|---|---|---|
readers | long | 0 | The number of reader threads in the thread pool, which are used for client notification. |
writers | long | 0 | The number of writer threads in the thread pool, which are used for client notification. |
workers | long | 0 | The number of worker threads in the thread pool, which are used for component notification. |
To enable EAServer to create multiple instances of a message-driven bean (MDB):
MyPkg/MyComp[threadsl]
.
Deleting a thread pool
If the message service cannot deliver a message, it moves the message to the dead message queue. You can view a list of these messages, delete them, or resend them to their original destination.
Viewing the dead message queue
Copyright © 2002 Sybase, Inc. All rights reserved. |
![]() |