1) Tibco EMS provides mechanisms for administering server operations and creating objects that are managed by the server, such as connection factories and destinations. EMS clients can retrieve references to these administered objects by using the JNDI.
2) Tibco EMS provides the ability for servers to route the messages between each other. Topic messages can be routed across multiple hops, Queue messages can travel at most one hop to any other server from the server that owns the queue.
3) Tibco EMS supports SSL. SSL is supported between the following componenets.
Between an EMS client and EMS server.
Between an administration tool and EMS server.
Between Routed Servers.
Between Fault-Tolerant servers.
4) Tibco EMS allows you to work with third-party naming/directory service providers or with third-party application servers.
5) Tibco EMS can integrate with Java Transaction API (JTA) compliant transaction managers.
6) JMS messages have the standard structure.
Header (required)
Properties (optional)
Body (optional)
JMS standard specifies two delivery modes, PERSISTENT and NON-PERSISTENT. Tibco EMS also includes RELIABLE_DELIVERY. RELIABLE_DELIVERY mode eliminates some of the over head associated with the other delivery modes.
| Table 1 Summary of message properties (Sheet 1 of 2) | ||
|
Property |
Description |
More Info |
| JMS_TIBCO_COMPRESS | Allows messages to be compressed for more efficient storage. | 65 |
| JMS_TIBCO_DISABLE_SENDER | Specifies that the user name of the message sender should not be included in the message, if possible. | 68 |
| JMS_TIBCO_IMPORTED | Set by the server when the message has been imported from TIBCO Rendezvous. | 86111 |
| JMS_TIBCO_MSG_EXT | Extends the functionality of map messages to include submessages or arrays. | 69 |
| JMS_TIBCO_MSG_TRACE | Specifies the message should be traced from producer to consumer. | 231 |
| JMS_TIBCO_PRESERVE_UNDELIVERED | Specifies the message is to be placed on the undelivered message queue if the message must be removed. | 67 |
| JMS_TIBCO_SENDER | Contains the user name of the message sender. | 68 |
7) Sample Comments from Queues.conf file, provided by tibco, it explains the properties that we can set for each destination.
Example :
prv.tlgapi.addequipmentupgrade.request.spm2 failsafe,global,maxbytes=100MB,flowControl=90MB,prefetch=64,maxRedelivery=3,expiration=5min
prv.tlgapi.addequipmentupgrade.response.spm2 failsafe,global,maxbytes=100MB,flowControl=90MB,prefetch=64,maxRedelivery=3,expiration=5min
Queue and topic properties can be set when the destination is created. Queue and topic properties can add the following functionality.
- A fail safe mode allows messages to be written to disk synchronously to guarantee no messages are ever lost due to server failure.
- Enforcement of permissions can be set at the queue or topic level so that some destinations may require access control and others may not.
- You can limit the size of messages stored on a queue. If a receiver is offline for a long time, queue messages can accumulate and consume machine resources.
- You can limit the size of messages stored for durable topic subscriptions. If a subscriber is offline for a long time, topic messages can accumulate and consume machine resources.
- Messages sent to destinations can be routed to other servers.
- You can exchange messages with other message services. Queues can receive TIBCO Rendezvous and TIBCO SmartSockets messages. Topics can either receive or send Rendezvous and TIBCO SmartSockets messages.
- Queues can be set to be exclusive or non-exclusive. Only one receiver can receive messages from an exclusive queue. More than one receiver can receive messages from non-exclusive queues.
- Queues can specify a redelivery policy. When messages must be redelivered, you can specify a property on the queue that determines the maximum number of times a message should be redelivered.
- All messages passing through a destination can be traced and logged.
- The user name of message producer that sends messages can be included in the message.
- TIBCO Enterprise Message Service allows you to create wildcard destinations. The wildcard destination name is the parent, and any names that match the wildcard destination name inherit the properties of the parent.
8) Java applications use the javax.jms package to send and receive messages. It is a set of interfaces specified by the JMS standard for creating connection to the EMS server. Com.tibco.tibems package provides the tibco EMS specific aspects.
9) There are 3 kinds of destinations.
1) Static Queues and topics (These destinations are created through the configuration files)
2) Dynamic Queues and Topics ( These are created on the fly by client applications)
3) Temporary Queues (Servers connected by Routes exchange messages sent to temporary queues, as a result temporary queues are ideal for reply messages in request/reply interactions.)
Dynamic queues and topics inherit properties from their respective parents. When shown by the administration tool, properties of a queue or topic may have an asterisk (*) character in front of its name. This means that this property was inherited from the parent queue or topic and cannot be changed. For more information, refer to Inheritance of Properties and Wildcards * and >.
10) Destination property Failsafe means: EMS provides 2 modes of persisting topic/queue messages to the external storage
normal (Writes all messages to the file on disk in asynchronous mode, data may remain in system buffers for a short time before it is written to disk, and may be lost when the software or hardware fails.)
failsafe (Failsafe mode writes data in synchronous mode, for cases where data loss is not acceptable this property should be set while creating the destinations. It affects the performance )
11) Destination property secure means: When secure property is enabled, it instructs the server to check user permissions whenever a user attempts to perform an operation on that destination.
The server authorization property acts as a master switch for checking permissions. That is, the server checks user permissions on secure destinations only when the authorization property is enabled. To enforce permissions, you must both enable the authorization configuration parameter, and set the secure property on each affected destination.
12) Destination property maxbytes means : topics and queues can specify maxbytes property in the form: maxbytes=b, where b is the number of bytes.
for queues, maxbytes defines the maximum size (in bytes) that the queue can store, summed over all the messages in the queue.
for topics, maxbytes limits the maximum size that the topic store for delivery to each durable subscriber on the topic.
13) Destination property maxMsgs means : Queues can specify maxMsgs property in the form maxmsgs=m, where m is the number of messages.
14) Destination property overflowpolicy means : Queues can specify overFlowPolicy property to change the effect of exceeding queue limits (either maxbytes or maxmsgs)
when overflowpolicy=discardOld, exceeding queue limits causes the server to discard the oldest message.
if not set the server refuses new messages for the queue.
15) Destination property global means: Messages destined for a queue or topic with the global property set are routed to the servers that are participating in routing with this server.
16) Destination property sender_name means:
The sender_name property specifies that the server may include the sender’s username for messages sent to this destination. When this property is enabled, the server takes the user name supplied by the message producer when the connection is established and places that user name into the JMS_TIBCO_SENDER property in the message.
17) Destination property sender_name_enforced means :
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.
18) Destination property flowControl means : The flowcontrol property specifies the target maximum size the server can use to store pending messages for a destination. This is useful when message producers sent messages much more quickly than message consumers can consume.
Flow control must be enabled for the server before the value in this property is enforced by the server.
19) Destination property trace means : Specifies that tracing should be enabled for this destination.
The property can be specified as either trace or trace=body.
20) Destination property import means : The import property allows messages published by an external system to be received by the TIBCO EMS destination, as long as the transport to the external system is configured.
21) Destination property export means : The export property allows messages published by a client to a topic to be exported to an external system with configured transports.
22) Destination Property maxRedelivery means : 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.
23) Destination property exclusive means: The property is available only for queues. When exclusive is enabled, server sends all the messages (on that queue) to only one customer.
24) Destination property non-exclusive queues & Round-Robin Delivery: With non-exclusive queues (exclusive set to false) the server distributes messages in a round-robin—one to each receiver that is ready.
25) Destination property Prefetch means: 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
The MessageConsumer and the server cooperate to regulate fetching according to the queue’s prefetch property.
| Table 5 Prefetch | |
|
Value |
Description |
| 2 or more | The MessageConsumer automatically fetches messages from the server. The MessageConsumer never stores more than this maximum number of messages. |
| 1 | The MessageConsumer automatically fetches messages from the server—initiating fetch only when it does not currently hold a message. |
| none | Disables automatic fetch. That is, the MessageConsumer initiates fetch only when the client calls receive—either an explicit synchronous call, or an implicit call (in an asynchronous receiver). |
| 0 | The queue inherits the prefetch value. If it has no parent, or no queue in the parent chain sets a value for prefetch, then the default value is 5.When a queue does not set any value for prefetch, then the default value is 0 (that is, inherit the prefetch value). |
26) Destination property Expiration means: 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.
Specify this value as an integer with units. Legal units are msec, sec, min, hour and day (for example, expiration=10min). When units are absent, the default unit is seconds.
27) Static queues and topics are assigned certain properties in the configuration file. These static queues and topics become the parents of the dynamic queues and topics, which inherit properties from the elements.
28) Wildcard “*” means nay 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.
29) Wildcard “>” matches one or more trailing elements.
for example foo.>, matches foo.bar and foo.bar.boo.
30) The flow_control parameter in tibemsd.conf enables and disables flow control globally for the TIBCO Enterprise Message Service server. When flow_control is disabled (the default setting), the server does not enforce any flow control on destinations. When flow_control is enabled, the server enforces any flow control settings specified for each destination.
31) JMS supports 2 message delivery modes, persistent and non-persistent modes. 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.
32) TIBCO Enterprise Message Service (release 4 and later) can exchange messages with TIBCO Rendezvous (release 6.9 and later).
Scope
- EMS can import and export messages to an external system through an EMS topic.
- EMS can import messages from an external system to an EMS queue (but queues cannot export).
Figure 13 Rendezvous Transports in the EMS Server
33) The parameter tibrv_transports (in the configuration file tibemsd.conf) globally enables or disables message exchange with Rendezvous. The default value is disabled. To use these transports, you must explicitly set this parameter to enabled.
34) Transport definitions (in the configuration file transports.conf) specify the communication protocol between EMS and the external system; for details, see Configuring Transports for Rendezvous.
35) timemsd connects to Rendezvous daemons in the same way as any other Rendezvous client would. Transport definitions (in the file transports.conf) configure the behavior of these connections. You must properly configure these transports.
36) Topics can both export and import messages. Accordingly, you can configure topic definitions (in the configuration file topics.conf) with import and export properties that specify one or more external transports:
37) Queues can import messages, but cannot export them.
38) The EMS server reads configuration files only once, when the server starts. It ignores subsequent changes to the configuration files.
39) You can also change the server configuration with administrative requests, using either tibemsadmin (a command line tool).
40) When the server validates and accepts an administrative request, it writes the change to the appropriate configuration file as well (overwriting any manual changes to that file). This policy keeps configuration files current in case the server restarts (for example, in a fault-tolerant situation, or after a hardware failure).
41)
The JMSDeliveryMode message header field defines the delivery mode for the message. JMS supports PERSISTENT and NON_PERSISTENT delivery modes for both topic and queue. EMS extends these delivery modes to include a RELIABLE_DELIVERY mode.
You can set the default delivery mode for the Message Producer, as described in Configuring a Message Producer. This default delivery mode can be overridden by the client when sending a message, as described in Sending Messages.
PERSISTENT
As shown in Figure 4, when a producer sends a PERSISTENT message, the producer must wait for the server to reply with a confirmation. The message is persisted on disk by the server. This delivery mode ensures delivery of messages to the destination on the server in almost all circumstances. However, the cost is that this delivery mode incurs two-way network traffic for each message or committed transaction of a group of messages.
Figure 4 Persistent Message Delivery
NON_PERSISTENT
Sending a NON_PERSISTENT message omits the overhead of persisting the message on disk to improve performance.
If authorization is disabled on the server, the server does not send a confirmation to the message producer.
If authorization is enabled on the server, the default condition is for the producer to wait for the server to reply with a confirmation in the same manner as when using PERSISTENT mode.
Regardless of whether authorization is enabled or disabled, you can use the npsend_check_mode parameter in the tibemsd.conf file to specify the conditions under which the server is to send confirmation of NON_PERSISTENT messages to the producer. See the description for the npsend_check_mode parameter on on page 169 for details.
Figure 5 Non-Persistent Message Delivery
RELIABLE_DELIVERY
EMS extends the JMS delivery modes to include reliable delivery. Sending a RELIABLE_DELIVERY message omits the server confirmation to improve performance regardless of the authorization setting.
Figure 6 Reliable Message Delivery
When using RELIABLE_DELIVERY mode, the server never sends the producer a receipt confirmation or access denial and the producer does not wait for it. Reliable mode decreases the volume of message traffic, allowing higher message rates, which is useful for messages containing time-dependent data, such as stock price quotations.
When you use the reliable delivery mode, the client application does not receive any response from the server. Therefore, all publish calls will always succeed (not throw an exception) unless the connection to the server has been terminated.
In some cases a message published in reliable mode may be disqualified and not handled by the server because the destination is not valid or access has been denied. In this case, the message is not sent to any message consumer. However, unless the connection to the server has been terminated, the publishing application will not receive any exceptions, despite the fact that no consumer received the message.
42) NON_PERSISTENT and RELIABLE_DELIVERY messages are never written to persistent storage. PERSISTENT messages are written to persistent storage when they are received by the EMS server.
43)
Persistent Messages Sent to Queues
Persistent messages sent to a queue are always written to disk. Should the server fail before sending persistent messages to subscribers, the server can be restarted and the persistent messages will be sent to the subscribers when they reconnect to the server.
Figure 7 Persistent Messages Sent to a Queue
44) Persistent Messages Published to Topics
Persistent messages published to a topic are written to disk only if that topic has at least one durable subscriber or one subscriber with a fault-tolerant connection to the EMS server. In the absence of a durable subscriber or subscriber with a fault-tolerant connection, there are no subscribers that need messages resent in the event of a server failure. In this case, the server does not needlessly save persistent messages. This improves performance by eliminating the unnecessary disk I/O to persist the messages.
Figure 8 Persistent Messages Published to a Topic
45) You can set the failsafe property on a topic or queue to specify that persistent messages for the topic or queue be synchronously written to disk. When failsafe is set, the producer remains blocked until the server has completed the write-to-disk operation.
46)
Message Acknowledgement
The interface specification for JMS requires that message delivery be guaranteed under many, but not all, circumstances. Figure 12 illustrates the basic structure of message delivery and acknowledgement.
Figure 12 Message Delivery and Acknowledgement
The following describes the steps in message delivery and acknowledgement:
- A message is sent from the message producer to the machine on which the EMS server resides.
- For persistent messages, the EMS server sends a confirmation to the procedure that the message was received.
- The server sends the message to the consumer.
- The consumer sends an acknowledgement to the server that the message was received. A session can be configured with a specific acknowledge mode that specifies how the consumer-to-server acknowledgement is handled. These acknowledge modes are described below.
- In many cases, the server then sends a confirmation of the acknowledgement to the consumer.
The JMS specification defines three levels of acknowledgement for non-transacted sessions:
CLIENT_ACKNOWLEDGEspecifies that the consumer is to acknowledge all messages that have been delivered so far by the session. When using this mode, it is possible for a consumer to fall behind in its message processing and build up a large number of unacknowledged messages.AUTO_ACKNOWLEDGEspecifies that the session is to automatically acknowledge consumer receipt of messages when message processing has finished.DUPS_OK_ACKNOWLEDGEspecifies that the session is to “lazily” acknowledge the delivery of messages to the consumer. “Lazy” means that the consumer can delay acknowledgement of messages to the server until a convenient time; meanwhile the server might redeliver messages. This mode reduces session overhead. However, should JMS fail, the consumer may receive duplicate messages.
EMS extends the JMS acknowledge modes to include:
The acknowledgement mode is set when creating a Session, as described in Creating a Session.
NO_ACKNOWLEDGE
NO_ACKNOWLEDGE mode suppresses the acknowledgement of received messages. 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.
| Sessions created in no-acknowledge receipt mode cannot be used to create durable subscribers. |
Also, queue receivers on a queue that is routed from another server are not permitted to specify NO_ACKNOWLEDGE mode.
EXPLICIT_CLIENT_ACKNOWLEDGE
EXPLICIT_CLIENT_ACKNOWLEDGE is like CLIENT_ACKNOWLEDGE except it acknowledges only the individual message, rather than all messages received so far on the session.
One example of when EXPLICIT_CLIENT_ACKNOWLEDGE would be used is when receiving messages and putting the information in a database. If the database insert operation is slow, you may want to use multiple application threads all doing simultaneous inserts. As each thread finishes its insert, it can use EXPLICIT_CLIENT_ACKNOWLEDGE to acknowledge only the message that it is currently working on.
EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE
EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE is like DUPS_OK_ACKNOWLEDGE except it ’lazily” acknowledges only the individual message, rather than all messages received so far on the session.
47) The EMS APIs allow for both synchronous or asynchronous message consumption. For synchronous consumption, the message consumer explicitly invokes a receive call on the topic or queue. When synchronously receiving messages, the consumer remains blocked until a message arrives. See Receiving Messages for details.
48) The consumer can receive messages asynchronously by registering a message listener to receive the messages. When a message arrives at the destination, the message listener delivers the message to the message consumer. The message consumer is free to do other operations between messages.
49) When authorization is enabled, the server requires a name and password before users can connect. Only authenticated users can connect to the server. The form of authentication can be either an X.509 certificate or a username and password (or both).
50) Even when authorization is enabled, the administrator (admin) may explicitly allow anonymous user connections, which do not require password authorization. To allow these connections, create a user with the name anonymous and no password.
51) For communication security between servers and clients, and between servers and other servers, you must explicitly configure SSL within EMS; see Using the SSL Protocol.
SSL communication requires software to implement SSL on both server and client. The EMS server includes the OpenSSL implementation. Java client programs must use either JSSE (part of the Java environment) or separately purchased SSL software from Entrust; neither of these are part of the EMS product. C client programs can use the OpenSSL library shipped with EMS.
52)autocommit [on|off]
When autocommit is set to on, the changes made to the configuration files are automatically saved to disk after each command. When autocommit is set to off, you must manually use
the commit command to save configuration changes to the disk.
By default, autocommit is set to on when interactively issuing commands.
Entering autocommit without parameters displays the current setting of autocommit (on or off)
53)
compact
compact store_type [max_time]
Compacts the database store files.
- To compact the asynchronous file, specify either
a,async, orasynchronous. - To compact the synchronous file, specify either
s,sync, orsynchronous.
Since compaction can be a lengthy operation, and it blocks other database operations, you may specify a time limit (in seconds). Zero is a special value, which specifies no time limit. When the time limit is absent, the default is zero, and the administration tool asks for confirmation.
We recommend compacting the database store files only when the database Used Space usage is 30% or less (see show db ).
54)
create rvcmlistener
create rvcmlistener [transportName] name subject
Registers an RVCM listener with the server so that any messages forwarded through a tibrvcm transport (including the first message sent) are guaranteed for the specified listener. This causes the server to perform the TIBCO Rendezvous call tibrvcmTransport_AddListener.
The parameters are:
- transportName — the name of the transport to which this RVCM listener applies. Note that the square brackets [ ] DO NOT indicate that the transport name is an option; they must be included around the name.
- name — the name of the RVCM listener to which topic messages are to be exported.
- subject — the RVCM subject name that messages are published to. This should be the same name as the topic names that specify the
exportproperty.
For more information, see tibrvcm.conf and Rendezvous Certified Messaging (RVCM) Parameters.
55)
rotatelog
rotatelog
Force the current log file to be backed up and truncated. The server starts writing entries to the newly empty log file.
The backup file name is the same as the current log file name with a sequence number appended to the filename. The server queries the current log file directory and determines what the highest sequence number is, then chooses the next highest sequence number for the new backup name. For example, if the log file name is tibems.log and there is already a tibems.log.1 and tibems.log.2, the server names the next backup tibems.log.3.
56) Example commands : show db, show config, show bridges, show server, show stat, whoami
The following tables summarize the parameters in tibemsd.conf according to category. The sections that follow provide more detail on each parameter.
Table 24 Global System Parameters
|
Parameter Name |
Description |
See Page |
authorization |
Enable or disable server authorization. | 167 |
flow_control |
Enable or disable flow control for destinations. | 167 |
listen |
Specifies the port on which the server is to listen for connections from clients. | 168 |
npsend_check_mode |
Specifies when the server is to provide confirmation upon receiving a NON_PERSISTENT message from a producer. |
169 |
password |
Password used to authenticate with other routed servers that have authorization enabled. |
170 |
routing |
Enable or disable routing functionality for this server. | 170 |
server |
Name of server. | 170 |
startup_abort_list |
Specifies conditions under which the server is to exit during its initialization sequence. | 170 |
user_auth |
Specifies the source of authentication information used to authenticate users attempting to access the EMS server. | 172 |
Table 25 Storage File Parameters
|
Parameter Name |
Description |
See Page |
store |
Specifies the directory in which the server stores data. | 173 |
store_crc |
Specifies whether the EMS server validates CRC checksum data when reading the store files. | 173 |
store_minimum |
Specifies the amount of disk space to preallocate for EMS store files. | 173 |
store_truncate |
Specifies whether the EMS server is to periodically truncate the storage files to relinquish unused disk space. | 173 |
Table 26 Connection and Memory Parameters
|
Parameter Name |
Description |
See Page |
max_connections |
Specifies the maximum number of simultaneous client connections to the server. | 174 |
max_msg_memory |
Specifies the maximum memory the server can use for messages. | 174 |
msg_swapping |
Enable or disable message swapping. | 174 |
reserve_memory |
Specifies the amount of memory to reserve for use in emergency situations. | 175 |
msg_pool_block_sizemsg_pool_size |
Specifies the size of the pool to be pre-allocated by the server to store messages. | 175 |
Table 27 Detecting Network Connection Failure Parameters
57) The logfile configuration parameter in tibemsd.conf controls the location and the name of the log file. The logfile_max_size configuration parameter allows you to specify the maximum size of the current log file. Set the parameter to 0 to specify no limit. Use KB, MB, or GB units.
Once the log file reaches its maximum size, it is copied to a file with the same name as the current log file except a sequence number is appended to the name of the backup file. The server queries the directory and determines the first available sequence number. For example, if the current log file is named tibems.log, the first copy is named tibems.log.1, the second is named tibems.log.2, and so on. You can move the files out of the log directory, if desired, and the next log file is determined based on the first available numbered backup in the log file directory.
You can also dynamically force the log file to be backed up and truncated using the rotatelog command in tibemsadmin. See Command Listing for more information about the rotatelog command.
58)
Tracing on the server: Trace messages can be sent to a log file, the console, or both. You configure tracing in the following ways:
- By configuring the
log_traceand/orconsole_traceparameters in thetibemsd.conffile; see Table 12. - By specifying the
-traceoption when starting the server - By using the
set servercommand when the server is running.
log_trace and console_trace can be used to configure what types of messages are to go to the log file and to the console.
Examples
The following example sets the trace log to only show messages about access control violations.
log_trace=ACL
The next example sets the trace log to show all default trace messages, in addition to SSL messages, but ADMIN messages are not shown.
log_trace=DEFAULT,-ADMIN,+SSL
The next example sends a trace message to the console when a TIBCO Rendezvous advisory message arrives.
console_trace=RVADV
59)
System Monitor Topics
The TIBCO Enterprise Message Service server can publish topic messages for several system events. For example, the server can publish a message when users connect or disconnect.
The TIBCO Enterprise Message Service server can publish messages to various topics when certain events occur. There are several types of event classes, each class groups a set of related events. For example, some event classes are connection, admin, and route. Each event class is further subdivided into the events for each class. For example, the connection class has two events: connect and disconnect. These event classes are used to group the system events into meaningful categories.
All system event topic names begin with $sys.monitor. The remainder of the name is the event class followed by the event. For example, the server publishes a message to the topic $sys.monitor.connection.disconnect whenever a client disconnects from the server. The naming scheme for system event topics allows you to create wildcard subscriptions for all events of a certain class. For example, to receive messages whenever clients connect or disconnect, you would create a topic subscriber for the topic $sys.monitor.connection.*.
Monitor topics are created and maintained by the server. Monitor topics are not listed in the topics.conf file. Users can subscribe to monitor topics but cannot create them.
60) The TIBCO Enterprise Message Service server tracks the number of incoming or outgoing messages, but only messages sent or received by a producer, consumer, or route are tracked. The server also sends system messages, but these are not included in the number of messages.
61) You can view overall server statistics by executing the show server command. The server_rate_interval configuration parameter controls the collection interval for server statistics. The parameter can be set in the configuration file or dynamically using the set server command. This parameter can only be set to positive integers greater than zero
62) Each producer, consumer, destination, and route can gather overall statistics and statistics for each of its destinations. To enable statistic gathering, you must set the statistics parameter to enabled. This parameter can be specified in the configuration file, and it can be changed dynamically using the set server command
To enable detailed statistics, set the detailed_statistics parameter to the type of statistics you wish to receive. The parameter can have the following values:
- NONE — disables detailed statistic gathering.
- CONSUMERS — enables detailed statistics for topic subscribers with wildcard topic names.
- PRODUCERS — enables detailed statistics for producers that do not specify a destination when they are created.
- ROUTES — enables detailed statistics for routes
63) When statistic collecting is enabled, you can view statistics for producers, consumers, routes, and destinations using the show stat command in the administration tool.
Fault Tolerance Overview
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. (We do 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.
Figure 21 illustrates a fault-tolerant configuration of TIBCO Enterprise Message Service.
Figure 21 Primary Server and Backup Server
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.
Configuration Files
When a primary server fails, its backup server assumes the status of the primary server and resumes operation. Before becoming the new primary server, the backup server re-reads all of its configuration files. If the two servers share configuration files, then administrative changes to the old primary carry over to the new primary.
krishna mullapudi technology blog 
Leave a comment