Friday, July 31, 2009

Using the configuration Files in EMS

The configuration files contain information about the various EMS objects like queues, topics, users, bridges etc. These files are located in TIBCO_HOME/ems/bin directory.

These files can be edited either directly using a textpad or using the command line based administration tool. The administration tool will eventually read/write to/from these configuration files.

Following are the key configuration files that are available in EMS server:

tibemsd.conf - This is the main configuration file. It has properties that are concerned with the EMS server.

queues.conf - Queue configuration file.

topics.conf - Topics configuration file.

users.conf - All users configuration file.

acl.conf - Permission settings for users on destinations.

routes.conf - Routes configuration file.

bridges.conf - Bridges configuration file.

factories.conf - Connection Factories configuration file.

Read more...

Wednesday, July 29, 2009

Wildcards in Topics and Queues

The wildcard * means that any token can be in the place of *.
For example: foo.* matches all two-part destination names beginning with foo. including foo.bar and foo.boo, but not foo.bar.boo.

The wildcard > matches one or more trailing elements. For example, foo.> matches foo.bar and foo.bar.boo

Wildcards in Topics:
  • You can subscribe to wildcard topics.
  • You cannot publish to wildcard topics.
  • If foo.bar is not in the configuration file, then you can publish to foo.bar if foo.* or foo.> exists in the configuration file.
Wildcards in Queues:

You can not send or receive to wildcard queue names. However, you can use wildcard queue names in the configuration files.

For example, if the queue configuration file includes a line:
foo.* then users can create queues foo.bar, foo.bob, and so forth, but not foo.bar.bob.

Read more...

Monday, July 27, 2009

Key Interfaces in EMS - MessageProducer, MessageConsumer and MessageListner

MessageProducer:



A MessageProducer object is created by a Session object and is used for sending messages to destinations. For example, using the mySession object created in Session , the following creates a MessageProducer that sends messages to a queue named myQueue:

MessageProducer myQueueSender = mySession.createProducer(myQueue);



Once you have created a MessageProducer, you can use it to send messages. For example, the following sends a message using the queueSender created above:


myQueueSender.send(message);



You can create MessageProducers that do not identify a destination. When the sender or publisher does not specify a destination, you must specify the destination when you send or publish a message as the first parameter of the send() or publish() method.



MessageConsumer:



A MessageConsumer object is created by a Session object and is used for receiving messages sent to destinations. For example, using the mySession object, the following creates a MessageConsumer that retrieves messages from a queue named myQueue:



MessageConsumer myQueueReceiver =
mySession.createConsumer(myQueue);



For queues, messages remain on the queue until they are consumed by a MessageConsumer, the message expiration time has been reached, or the maximum size of the queue is reached.



a) Durable Subscribers for Topics: Only MessageConsumers whose client applications are running receive messages published on a topic. Optionally, Sessions can create durable subscribers to ensure that messages are received, even if the application is not currently running.



(b) Synchronous or Asynchronous Messages: The API allows for synchronous or asynchronous message consumption. For synchronous consumption, the MessageConsumer explicitly calls the receive() method on the topic or queue. For asynchronous consumption, the client registers a MessageListener for the topic or queue. When a message arrives at the destination, the TIBCO Enterprise Message Service server delivers the message by calling the listener’s onMessage() method.



MessageListner:

A MessageListener object acts as an asynchronous event handler for messages. This object implements the MessageListener interface and has one method, onMessage().The onMessage() method is called by the TIBCO Enterprise Message Service server when a message arrives on a destination. You implement the onMessage() method in your MessageListener class to perform the desired actions when a message arrives. Your implementation should handle all exceptions, and it should not throw any exceptions.



Once you create a MessageListener object, you must register it with a specific MessageConsumer. The following creates a queueListener (an implementation of the MessageListener interface) and registers it with the QueueReceiver object:



MessageListener queueListener = new MessageListener();
myQueueReceiver.setMessageListener(queueListener);



You should register the MessageListener with the MessageConsumer before calling the Connection’s start () method to begin receiving messages.

Read more...

Saturday, July 25, 2009

Key Interfaces in EMS - ConnectionFactory, Connection and Session

ConnectionFactory:



The ConnectionFactory object encapsulates a set of connection configuration parameters. When a client starts, it typically performs a Java Naming and Directory Interface (JNDI) lookup for the ConnectionFactories that it needs. For example, the following code retrieves the InitialContext using the JNDI properties specified by env, then looks up a ConnectionFactory named myConnectionFactory.



Context ctx = new InitialContext(env);
ConnectionFactory myConnectionFactory =
(ConnectionFactory) ctx.lookup("myConnectionFactory");



Connection:



A Connection object encapsulates a virtual connection with the server.
ConnectionFactory objects create Connection objects. You use a Connection to create one or more Session objects. For example, the following creates a Connection:

Connection myConnection =
myConnectionFactory.createConnection()



When a client application completes, all open connections must be closed. Unused open connections are eventually closed, but they do consume resources that could be used for other applications. Closing a connection also closes any Sessions created by the Connection. To close a connection, use the close() method. For example:


myConnection.close();



Session:
A Session is a single-threaded context for producing or consuming messages. You create MessageProducers or MessageConsumers using Session objects. For example, using the myConnection object created in Connection above, the following creates a Session:


Session mySession =

myConnection.createSession(false, Session.AUTO_ACKNOWLEDGE);


The first parameter to the CreateSession() method determines whether the Session is transactional or not. The second parameter specifies the acknowledge mode of messages received by the session.



The remaining Key Interfaces will be explained in tomorrow's posting.

Read more...

Friday, July 24, 2009

Destination Bridges, Routes and Flow Control

Destination bridges and flow control

Please read Bridges before reading this topic

Flow control can be specified on destinations that are bridged to other destinations. If you wish the flow of messages sent by way of the bridge to slow down when receivers on the bridged-to destination cannot process the messages quickly enough, you must set the flowControl property on both destinations on either side of the bridge.

Routes and flow Control
For global topics where messages are routed between servers, flow control can be specified for a topic on either the server where messages are produced or the server where messages are received.

If the flowControl property is set on the topic on the server receiving the messages, when the pending message size limit is reached, messages are not forwarded by way of the route until the topic subscriber receives enough messages to lower the pending message size below the specified limit.

If the flowControl property is set on the topic on the server sending the messages, the server may block any topic publishers when sending new messages if messages cannot be sent quickly enough by way of the route. This could be due to network latency between the routed servers or it could be because flow control on the other server is preventing new messages from being sent.

Read more...

Thursday, July 23, 2009

Control access to the EMS Server:Authentication and Permissions

TIBCO Enterprise Message Service allows you to control access to the server by creating users and assigning passwords, creating groups, setting permissions etc. The server can also authenticate users defined in an external directory (such as an LDAP server)

Permissions for all users and groups must be defined in the access control list for the TIBCO Enterprise Message Service server. There are also administrator permissions that allow administrators to control which actions users can perform on the server such as create destinations, modify users, and view routes. Administrator permissions can apply globally, or they can be granted on specific destinations.

Enabling Access Control
There are two levels where authorization is set.


Server: The authorization property in the main configuration file enables or disables the checking of permissions for all destinations managed by the server. The authorization property also enables or disables verification of user names and passwords.

To enable authorization, edit the tibemsd.conf file:
authorization = enabled


From the command line admin utility:


set server authorization = enabled



If this is not set, then the server allows any client connection and no permissions are checked on any destination. Enabling authorization immediately applies to existing client connections (except route connections). The server begins checking permissions.

Destination: The secure property of the destinations is used to allow the server to check permissions of a client connection for that particular destination when a user attempts to perform any operation on that destination

Setting Permissions
Permissions are stored in the access control list and determine the actions a user can perform on a destination. Permissions can only be granted by users that have the appropriate administrator permissions.


Please go through the corresponding chapter in the JMS documentation for further detailed information

Read more...

Tuesday, July 21, 2009

Failover in EMS

Step 1
A backup server detects a failure of the primary in either of two ways:
  • Heartbeat Failure—the primary server sends heartbeat messages to the backup server to indicate that it is still operating. When a network failure stops the servers from communicating with each other, the backup server detects the interruption in the steady stream of heartbeats.
  • Connection Failure—the backup server can detect the failure of its TCP connection with the primary server. When the primary process terminates unexpectedly, the backup server detects the broken connection.

Step2
When a backup server (B) detects the failure of the primary server (A), then B attempts to assume the role of primary server. First, B obtains the lock on the current shared state. When B can access this information, it becomes the new primary server.

  • If B cannot obtain the lock immediately, it alternates between attempting to obtain the lock (and become the primary server), and attempting to reconnect to A (and resume as a backup server)—until one of these attempts succeeds.
  • When server A comes back again, it becomes a backup server and server B continues to be the primary.
  • Clients of A that are configured to failover to backup server B automatically transfer to B when it becomes the new primary server.

Step 3:

After a failure, message redelivery is attempted based on the type of messages and destination configuration.

  • Persistent: When a failure occurs, messages with delivery mode PERSISTENT, that were not successfully acknowledged before the failure, are redelivered.
  • Failsafe: EMS guarantees that a message with PERSISTENT delivery mode and a failsafe destination will not be lost during a failure.
  • Any messages that have been successfully acknowledged or committed are not redelivered, in compliance with the JMS 1.1 specification.
  • All topic subscribers continue normal operation after a failover.
  • Queues: For queue receivers, any messages that have been sent to receivers, but have not been acknowledged before the failover, may be sent to other receivers immediately after the failover. A receiver trying to acknowledge a message after a failover may receive the javax.jms.IllegalStateException. This exception signifies that the attempted acknowledgement is for a message that has already been sent to another queue receiver.
  • After a failover, attempting to commit the active transaction results in a javax.jms.TransactionRolledBackException. Clients that use transactions must handle this exception, and resend any messages sent during the transaction.

Read more...

Monday, July 20, 2009

Configuring the Fault Tolerant Servers

To configure an EMS server as a fault-tolerant backup, set these parameters in its main configuration file (or on the server command line):
  • server Set this parameter to the same server name in the configuration files of both the primary server and the backup server.
  • ft_active In the configuration file of the primary server, set this parameter to the URL of the backup server. In the configuration file of thebackup server, set this parameter to the URL of the primary server.

When the backup server starts, it attempts to connect to the primary server. If it establishes a connection to the primary, then the backup server enters standby mode. If it cannot establish a connection to the primary, then the backup server assumes the role of the primary server (in active mode). While the backup server is in standby mode, it does not accept connections from clients.



To administer the backup server, the admin user can connect to it using the administration tool



When a backup server assumes the role of the primary server during failover, clients attempt to reconnect to the backup server (that is, the new primary) and continue processing their current message state. As each client reconnects, the backup server reads its message state from the shared state files. You can instruct the server to clean up state information for clients that do not reconnect before a specified time limit.



The ft_reconnect_timeout configuration parameter specifies that time limit (in seconds). The default value is 60 seconds

Read more...

Saturday, July 18, 2009

Fault Tolerance in EMS

You can arrange TIBCO Enterprise Message Service servers for fault-tolerant operation by configuring a pair of servers—one primary and one backup. The primary server accepts client connections, and interacts with clients to deliver messages. If the primary server fails, the backup server resumes operation in its place. (EMS does not support more than two servers in a fault-tolerant configuration.)


Shared State: A pair of fault-tolerant servers must have access to shared state, which consists of information about client connections and persistent messages. This information enables the backup server to properly assume responsibility for those connections and messages.

Server state includes 3 categories of information:

  • Persistent messages

  • Client connections of the primary server

  • Metadata about message delivery (stored in the meta.db file)

Persistent messages are stored in 2 files: async-msgs.db file, which contains all the messages stored under normal mode, and sync-msgs.db file that contains all messages that are for failsafe destinations


Locking: To prevent the backup server from assuming the role of the primary server, the primary server locks the shared state during normal operation. If the primary server fails, the lock is released, and the backup server can obtain the lock.


Click to read about Configuring Fault Tolerance.

Read more...

Thursday, July 16, 2009

EMS Message Delivery Mode Extensions (Reliable Message Delivery): PERSISTENT and NON PERSISTENT

TIBCO Enterprise Message Service(EMS) introduces two types of message delivery which are extensions to the JMS specification.

JMS delivery requirements ensure the delivery of all messages in almost all circumstances. However this requirements leads to a lot of overheads in the sense of network traffic (message and a return message confirming the receipt of the message) and the memory allocated for each persistent message and durable subscriber.

For higher throughput, EMS has come up with 2 ways of reducing the above overheads:
  • Reliable Message Delivery
  • No-Acknowledgement Delivery receipt

Reliable Message Delivery:


JMS has PERSISTENT and NON_PERSISTENT delivery modes for both topic and queue. In addition to these modes, you can use Tibjms.RELIABLE_DELIVERY mode from TIBCO Enterprise Message Service.

PERSISTENT and NON_PERSISTENT delivery require the server to return a system message to the client application to ensure proper handling of messages. In reliable delivery mode, the client application does not wait for this system message. Thus, reliable mode decreases the volume of message traffic, allowing better usage of system resources, and higher message rates.



No-Acknowledgement Message Receipt:


In no-acknowledge receipt mode, after the server sends a message to the client, all information regarding that message for that consumer is eliminated from the server. Therefore, there is no need for the client application to send an acknowledgement to the server about the received message. Not sending acknowledgements decreases the message traffic and saves time for the receiver, therefore allowing better utilization of system resources.

Read more...

Wednesday, July 15, 2009

Undelivered Message Queue in EMS

If a message is to be removed from the system in any way besides being properly consumed by a message consumer, the server checks the message for the JMS_TIBCO_PRESERVE_UNDELIVERED property.
When JMS_TIBCO_PRESERVE_UNDELIVERED is set to true, the server moves the message to the undelivered message queue.

$sys.undelivered
This undelivered message queue is a system queue that is always present and can not be deleted.

Read more...

Tuesday, July 14, 2009

Message Acknowledgements in EMS

This post is the continuation of the Previous posts, So please read those also.
There are 3 levels of acknowledgements:
  1. DUPS_OK_ACKNOWLEDGE, for consumers that are tolerant of duplicate messages.
  2. AUTO_ACKNOWLEDGE, in which the session automatically acknowledges a client’s receipt of a message.
  3. CLIENT_ACKNOWLEDGE, in which the client acknowledges the message by calling the message’s acknowledging method.

The following describes the steps in message delivery and acknowledgement:

  1. A message is sent from the message producer to the machine on which the TIBCO Enterprise Message Service server resides.
  2. The EMS server acknowledges that the message was received.
  3. The server sends the message to the consumer.
  4. The consumer sends acknowledgement to the server that the message was received.
  5. In many cases, the server then confirms acknowledgement to the consumer. Acknowledgement from the consumer to the server prevents the delivery of duplicate messages.

Read more...

Monday, July 13, 2009

Message delivery modes- persistent and non-persistent

JMS defines two message delivery modes, persistent and non-persistent. This mode is set by the message sender or publisher in the JMSDeliveryMode message header field.

Non-Persistent messages are never written to persistent storage. Persistent messages are logged to persistent storage when they are sent. Messages with the persistent delivery mode are always written to persistent storage, except when they are published to a topic that has no durable subscribers. When a topic has no durable subscribers, there are no subscribers that need messages resent in the event of a server failure. Therefore, messages do not need to be saved, and performance is improved because disk I/O is not required.

Read more...

Thursday, July 9, 2009

Bridges between Destinations

You can create bridges between destinations so that messages sent to one destination are also delivered to all bridged destinations. Bridges are created between one destination and one or more other destinations of the same or of different types. That is, you can create a bridge from a topic to a queue or from a queue to a topic.



Why Bridge destinations?
Some applications require the same message to be sent to more than one destination, possibly of different types. For example, an application may send messages to a queue for distributed load balancing. That same application, however, may also need the messages to be published to several monitoring applications. Another example is an application that publishes messages to several topics. All messages however, must also be sent to a database for backup and for data mining. A queue is used to collect all messages and send them to the database.



Bridges are not transitive and they are uni-directional. That is, if there is a bridge between A to B, then message sent to A can only flow to B and not the other way. Similarly, if there is a bridge between destination A to B and another bridge between destination B and C. Then any message sent to A will flow to B but not to C.

  • Selecting Messages: By default, all messages sent to a destination with a bridge are sent to all bridged destinations. This can cause unnecessary network traffic if each bridged destination is only interested in a subset of the messages sent to the original destination. You can optionally specify a message selector for each bridge to determine which messages are sent over that bridge.
  • Access Control: Message producers must have access to a destination in order to send messages to that destination. Messages can only be sent to bridged destinations to which the message producer has access.
  • Transactions: When a message producer sends a message within a transaction, all messages sent across a bridge are part of the transaction. Therefore, if the transaction succeeds, all messages are delivered to all bridged destinations. If the transaction fails, no consumers for bridged destinations receive the messages.

Read more...

Wednesday, July 8, 2009

Destination(Queues & Topics) Properties-5

This post is the continuation of the Previous posts, So please read that properties also.

12. exclusive: Only Queues
It defines how the server delivers messages to queue consumers when multiple queue consumers are present. In exclusive mode, the first queue consumer receives all of the messages until the consumer fails. At that point, messages are delivered to the next consumer. The first queue consumer is the first-activated queue receiver.

With non-exclusive queues (exclusive set to false) the server distributes messages in a round-robin—one to each receiver that is ready. If any receivers are still ready to accept additional messages, the server distributes another round of messages—one to each receiver that is still ready. When none of the receivers are ready to receive more messages, the server waits until a queue receiver reports that it can accept a message. This arrangement prevents a large buildup of messages at one receiver and balances the load of incoming messages across a set of queue receivers.

13. prefetch: Only Queues
Delivering messages from the server to a client program involves two independent phases—fetch and accept:
1. The fetch phase is a two-step interaction between a MessageConsumer object (in a client program) and the server.
  • The MessageConsumer initiates the fetch phase by signalling to the server that it is ready for more messages.
  • The server responds by transferring one or more messages to the client, which stores them in the MessageConsumer object.

2. In the accept phase, client code takes a message from the MessageConsumer object.
To reduce waiting time for client programs, the MessageConsumer can prefetch messages—that is, fetch a batch of messages from the server, and hold them for client code to accept, one by one. It can improve performance by decreasing or eliminating client idle time while the server transfers a message.



Different values,
prefetch=none, disable automatic prefetching
prefetch=0, inherit from the parent or set default value which is 5prefetch=n, prefetch n number of messages from server



14. expiration
The server’s expiration property overrides expiration values set by message producers (in client programs). You can set this property for any queue and any topic.
If this property is set for a destination, then when the server delivers a message to that destination, the server replaces the producer’s expiration value with this value.

Read more...

Tuesday, July 7, 2009

Destination(Queues & Topics) Properties-4

This post is the continuation of the Previous posts, So please read that properties also.

9. import: Both Queues and Topics
The import property allows messages published by an external system to be received by a TIBCO Enterprise Message Service destination (a topic or a queue), as long as the transport to the external system is configured. Currently you can configure transports for TIBCO Rendezvous reliable and certified messaging protocols. You can specify the name of one or more transports of the same type in the import property.

10. export: Only Queues
The export property allows messages published by a client to a topic to be exported to the external systems with configured transports. Currently you can configure transports for Rendezvous reliable and certified messaging protocols. You can specify the name of one or more transports of the same type in the export property.

11. maxRedelivery: Only queues
The maxRedelivery property specifies the number of attempts the server should make to redeliver a message sent to a queue. The value of this parameter can be set to an integer between 2 and 255. Once the server has attempted to deliver the message the specified number of times, the message is either destroyed or it is placed on the undelivered queue, if the JMS_TIBCO_PRESERVE_UNDELIVERED property on the message is set to true.

Note:The remaining Properties of Destinations will be posted in coming days, Please check for this blog updates daily to keep in touch.

Read more...

Monday, July 6, 2009

Destination(Queues & Topics) Properties-3

This post is the continuation of the Previous posts, So please read that properties also.

6. sender_name_enforced: Both Queues and Topics
The sender_name_enforced property specifies that messages sent to this destination must include the sender’s user name. The server retrieves the user name of the message producer using the same procedure described in the sender_name property above. However, unlike, the sender_name property, there is no way for message producers to override this property.

7. flowControl: Both Queues and Topics
The flowControl property specifies the target maximum size the server can use to store pending messages for the destination. This is useful when message producers send messages much more quickly than message consumers can consume them. You can specify the flowControl property without a value to set it to the default of 256KB. Flow control must be enabled for the server before the value in this property is enforced by the server.

Setting flow Control
First enable flow control by setting flow_control=enabled in the tibemsd.conf file. Then set the flowControl property to the desired value (in bytes) on that destination.

How it works
When the storage for pending messages is near the specified limit, the server blocks all new calls to send a message from message producers. The calls do not return until the storage has decreased below the specified limit. Once message consumers have received messages and the pending message storage goes below the specified limit, the server allows the send message calls to return to the caller and the message producers can continue processing.

8. trace: Both Queues and Topics
Specifies that tracing should be enabled for this destination. This property can be specified as either trace or trace=body. Specifying trace (without =body), generates trace messages that include only the message sequence and message ID.

Note:The remaining Properties of Destinations will be posted in coming days, Please check for this blog updates daily to keep in touch.

Read more...

Saturday, July 4, 2009

Destination(Queues & Topics) Properties-2

This post is the continuation of the Previous post, So please read that properties also.

3. maxBytes: Both for Queues and topics
This property is useful for limiting the pending messages on each destination.
For Queues, it defines the maximum size (in bytes) of all messages that can be waiting in the queue. By default, or if maxbytes is set to 0, there is no limit to the size of a queue. If a receiver is off-line for a long time, maxbytes limits the memory allocation for the receiver’s pending messages. Messages that would exceed the limit will not be accepted into storage and an error is returned to the message producer.

For Topics maxbytes limits the total size (in bytes) of all messages waiting for delivery to each durable subscriber on that topic. The limit applies separately to each durable subscriber on the topic. For example, when a durable subscriber is off-line for a long time, pending messages accumulate in the server; maxbytes limits the memory allocation for those pending messages for the subscriber; when the subscriber consumes messages (freeing storage) the topic can deliver additional messages.

4. global: Both Queues and Topics
Messages destined for a topic or queue with the global property set are routed to the other servers that are participating in routing with this server.

5. sender_name: Both Queues and Topics
If this property is set on the destination, then server copies the username of the client to the message header property: JMS_TIBCO_SENDER. However if the tibco sender sets the property JMS_TIBCO_DISABLE_SENDER, it can override the behavior of sender_name and the sender name will not be copied by the server.

Note:The remaining Properties of Destinations will be posted in coming days, Please check for this blog updates daily to keep in touch.

Read more...

Friday, July 3, 2009

Destination(Queues & Topics) Properties-1

Destination properties are properties that can be applied to queues and/or topics that describe specific behavior of the destination. Each property is described in short and please refer the EMS documentation for deeper understanding.


1. Failsafe: For Both Queue and Topic


TIBCO Enterprise Message Service provides two modes for persisting topic/queue messages in external storage. These two modes are:

  • normal
  • failsafe

In Normal mode all persistent messages are written to the storage in an asynchronous mode, ie data may be in the system buffers for a short duration before written to the disk.

Whereas in failsafe mode, data is not retained in the buffers and written to the disk synchronously. This ensures that in case of any software or hardware failure data is not lost.

In situations where loss of data is not acceptable, use failsafe. One should keep in mind that failsafe mode is a performance hit and should analyze and carefully use this property based on the need.



2. secure: Both for Queue and Topic



The secure property, when set on a destination, specifies permissions should be checked for that destination. When a topic or a queue does not have the secure property turned on, any authenticated user can perform any actions with that topic or queue. When the property is turned on, the administrator can assign permissions to the users. For this property to work, the authorization property must also be enables at the server level configuration file.



Note:The remaining Properties of Destinations will be posted in coming days, Please check for this blog updates daily to keep in touch.

Read more...

Thursday, July 2, 2009

TIBCO EMS Destinations:Queues & Topics

Destinations for messages can be either Topics or Queues. A destination can be created statically in the server configuration files, or dynamically by a client application.

Static Queues and Topics
Static Queues and topics are administered by the server. The configuration information is stored in the configuration files for the Tibco EMS server, which is located in TIBCO_HOME/ems/bin folder. The files are queues.conf and topics.conf. Changes to the configuration information can be made in a variety of ways. To manage static destinations, you can edit the configuration files using a text editor or you can use the administration tool. An EMS Client retrieves the destination information from the JNDI.

Dynamic Queues and Topics
Dynamic queues and topics are created on-the-fly by applications using
QueueSession.createQueue() and TopicSession.createTopic(). Dynamic
queues and topics do not appear in the configuration files, and exist as long as there are messages or consumers on the destination. A client cannot use JNDI to lookup dynamic queues and topics.When you use the show queues or show topics command in the administration tool, you see both static and dynamic topics and queues. The dynamic topics and queues have an asterisk (*) in front of their name in the list of topics or queues.

Temporary Queues and Topics
Servers connected by routes exchange messages sent to temporary topics. As a result, temporary topics are ideal destinations for reply messages in request/reply interactions.

To read Properties of destinations ClickHere

Read more...

Popular Posts

  © Blogger templates The Professional Template by Ourblogtemplates.com 2008

Back to TOP