TIBCO EMS – Properties of Queues and Topics (Where Tuning can be done)

You can set the properties directly in the topics.conf or queues.conf file or by means of the setprop topic or setprop queue command in the EMS Administrator Tool.

1)   Failsafe

The failsafe property determines whether the server writes persistent messages to disk synchronously or asynchronously.

Ø  When failsafe is not set, messages are written to the file on disk in asynchronous mode to obtain maximum performance. In this mode, the data may remain in system buffers for a short time before it is written to disk and it is possible that, in case of software or hardware failure, some data could be lost without the possibility of recovery

Ø  In failsafe mode, all data for that queue or topic are written into external storage in synchronous mode. In synchronous mode, a write operation is not complete until the data is physically recorded on the external device

The failsafe property ensures that no messages are ever lost in case of server failure

2) Secure

Ø  When the secure property is enabled for a destination, it instructs the server to check user permissions whenever a user attempts to perform an operation on that destination.

Ø  If the secure property is not set for a destination, the server does not check permissions for that destination and any authenticated user can perform any operation on that topic or queue.

2)   Maxbytes

Ø  Topics and queues can specify the maxbytes property in the form:

Maxbytes=value [KB|MB|GB]                   Ex: maxbytes=1000MB

Ø  For queues, maxbytes defines the maximum size (in bytes) that the queue can store, summed over all messages in the queue. Should this limit be exceeded, messages will be rejected by the server and the message producers send calls will return an error

Ø  If maxbytes is zero, or is not set, the server does not limit the memory allocation for the queue

Ø  For queues, maxbytes defines the maximum size (in bytes) that the queue can store, summed over all messages in the queue. Should this limit be exceeded, messages will be rejected by the server and the message producer sends calls will return an error

4) maxmsgs

Ø  Where value defines the maximum number of messages that can be waiting in a queue. When adding a message would exceed this limit, the server does not accept the message into storage, and the message producer’s send call returns an error.

Ø  If maxmsgs is zero, or is not set, the server does not limit the number of messages in the queue.

Ø  You can set both maxmsgs and maxbytes properties on the same queue. Exceeding either limit causes the server to reject new messages until consumers reduce the the queue size to below these limits.

5) OverflowPolicy

Topics and queues can specify the overflowPolicy property to change the effect of exceeding the message capacity established by either maxbytes or maxmsgs.

o   OverflowPolicy=default | discardOld | rejectIncoming

  1. Default

Ø  For topics, default specifies that messages are sent to subscribers, regardless of maxbytes or maxmsgs setting.

Ø  For queues, default specifies that new messages are rejected by the server and an error is returned to the producer if the established maxbytes or maxmsgs value has been exceeded.

  1. DiscardOld

Ø  For topics, discardOld specifies that, if any of the subscribers have an outstanding number of undelivered messages on the server that are over the message limit, the oldest messages are discarded before they are delivered to the subscriber.

Ø  The discardOld setting impacts subscribers individually. For example, you might have three subscribers to a topic, but only one subscriber exceeds the message limit. In this case, only the oldest messages for the one subscriber are discarded, while the other two subscribers continue to receive all of their messages.

Ø  For queues, discardOld specifies that, if messages on the queue have exceeded the maxbytes or maxmsgs value, the oldest messages are discarded from the queue and an error is returned to the message producer

        III.                rejectIncoming

Ø  For topics, rejectIncoming specifies that, if any of the subscribers have an outstanding number of undelivered messages on the server that are over the message limit, all new messages are rejected and an error is returned to the producer.

Ø  For queues, rejectIncoming specifies that, if messages on the queue have exceeded the maxbytes or maxmsgs value, all new messages are rejected and an error is returned to the producer.

6) global

Ø  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.

You can set global using the form:   global

7) sender_name

Ø  The sender_ name property specifies that the server may include the sender’s username for messages sent to this destination.

You can set sender_name using the form:    sender_name

8) sender_name_enforced

Ø  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.

You can set sender_name_enforced using the form:    sender_name_enforced

Ø  If the sender_name property is also set on the destination, this property overrides the sender_name property.

9) FlowControl

Ø  The flowControl property specifies the target maximum size the server can use to store pending messages for the destination. Should the number of messages exceed the maximum; the server will slow down the producers to the rate required by the message consumers. This is useful when message producers send messages much more quickly than message consumers can consume them.

If you specify the flowControl property without a value, the target        maximum is set to 256KB.

Ø  The flow_control parameter in tibemsd.conf file must be set to enable before the value in this property is enforced by the server. See Flow Control for more information about flow control.

10) trace

Ø  Specifies that tracing should be enabled for this destination.

o    You can set trace using the form:    trace [=body]

Ø  Specifying trace (without =body), generates trace messages that include only the message sequence and message ID. Specifying trace=body generates trace messages that include the message body

11) import

Ø  The import property allows messages published by an external system to be received by an EMS destination (a topic or a queue), as long as the transport to the external system is configured.

o    You can set import using the form:    import=”list

12) export

Ø  The export property allows messages published by a client to a topic to be exported to the external systems with configured transports.

o    You can set import using the form:    export=”list

Ø  It supports for only topics not queues.

13) maxRedelivery

Ø  The maxRedelivery property specifies the number of attempts the server should make to redeliver a message sent to a queue.

o    You can set maxRedelivery using the form:    maxRedelivery=count

Ø  Where count is an integer between 2 and 255 that specifies the maximum number of times a message can be delivered to receivers. A value of zero disables maxRedelivery, so there is no maximum.

Ø  Once the server has attempted to deliver the message the specified number of times, the message is either destroyed or, if the JMS_TIBCO_PRESERVE_UNDELIVERED property on the message is set to true, the message is placed on the undelivered queue so it can be handled by a special consumer

Undelivered Message Queue

If a message expires or has exceeded the value specified by the maxRedelivery property on a queue, the server checks the message’s JMS_TIBCO_PRESERVE_UNDELIVERED property. If
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 cannot be deleted. If JMS_TIBCO_PRESERVE_UNDELIVERED is set to false, the message will be deleted by the server.

14) exclusive

Ø  The exclusive property is available for queues only (not for topics).

Ø  When exclusive is set for a queue, the server sends all messages on that queue to one consumer. No other consumers can receive messages from the queue. Instead, these additional consumers act in a standby role; if the primary consumer fails, the server selects one of the s   tandby consumers as the new primary, and begins delivering messages to it.

Ø  By default, exclusive is not set for queues and 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.

15) prefetch

The message consumer portion of a client and the server cooperate to regulate fetching according to the prefetch property. The prefetch property applies to both topics and queues.

You can set  prefetch using the form:  prefetch=value

where value is one of the values in 2 0r more ,1,0,None.

Value Description

Ø  2 or more: The message consumer automatically fetches messages from the

server. The message consumer never fetches more than the number of messages specified by value.

Ø  1 :-The message consumer automatically fetches messages from the server initiating fetch only when it does not currently hold amessage.

Ø  None:-Disables automatic fetch. That is, the message consumer initiates fetch only when the client calls receive—either an explicit synchronous call, or an implicit call (in an asynchronous consumer).This value cannot be used with topics or global queues.

Ø  0:-The destination inherits the prefetch value from a parent

destination with a matching name. If it has no parent, or nodestination in the parent chain sets a value for prefetch, then the default value is 5 queues and 64 for topics.

Ø  When a destination does not set any value (i.e prefetch value is empty)for prefetch, then the default value is 0 (zero; that is, inherit the prefetch value).

16) expiration                                                                                    

Ø  If an expiration property is set for a destination, when the server delivers a message to that destination, the server overrides the JMSExpiration value set by the producer in the message header with the time specified by the expiration property.

o    You can set the expiration property for any queue and any topic using the form:

expiration=time [msec|sec|min|hour|day]

 

Ø  where time is the number of seconds. Zero is a special value that indicates messages to the destination never expire.

EMS Queue Requester v/s EMS Queue Sender

JMS queue Sender: – It simply sends the message to specified queue and does not wait for any response.

JMS Queue Requestor: – It send the message to specified queue and waits for the response from JMS client   like SOAP request reply activity.

The flow will not proceed until it gets the response or the request gets timed out. This activity uses temporary queues to ensure that reply messages are received only by the process that sent the request. 

Input tab :-

Queue

Reply to Queue :- It is the name of the queue in which this activity is awaiting for the reply . If leave blank,then a temporary queue  will be automatically created by Tibco as shown below in the screenshot.

(Run show queues command in the Tibco EMS admin .All the queues starting with * is either temporary or dynamic queues)

Queue-1

We can also give the name of Temporary queue.

Request Timeout :- If the response come within the time limit specified then flow will proceed if not then the flow will error out.

We have to use  Reply to JMS Message  activity to reply the message pending on the temporary queue.Once the message is response is send back to  the  temporary queue, it will get automatically deleted.

Please find the screenshot below for reference :-

Queue1-1

Queue1-2

Tibco EMS FAQs

 

What are the messaging models does EMS support?
Point-to-Point (Queue)
b. Publish and Subscribe (Topic)
c. Multicast (Topic)

There are two major models for messaging supported by JMS: queues and topics. Queues are based on a point-to-point messaging model. Topics make use of the new publish-and-subscribe messaging model.

Regardless whether queues or topics are used, the messages are not sent directly peer-to-peer. Messages are forwarded to a JMS infrastructure that is composed of one or more JMS servers. The servers are responsible for providing the quality-of-services to JMS and responsible for implementing all the components not addressed by JMS Specification.

When determining when to use queues versus topics consider the two fundamental messaging mechanisms. The first is point-to-point messaging, in which a message is sent by one publisher (sender) and received by one subscriber (receiver). The second is publish-subscribe messaging, in which a message is sent by one or more publishers and received by one or more subscribers. The messaging model as listed below will dictate when to use a queue or a topic:

One-to-one messaging                   Queue    point-to-point
One-to-many messaging   Topic   publish-subscribe
Many-to-many messaging   Topic    publish-subscribe model

What is the difference between a topic and queue?
Answer:

Topic-synchronous mode of communication.
-publisher and subscriber model.
-broad cast type messaging.
-there is no guarantee of delivery.
Queue-asynchronous mode of communication.
-point to point model.
-unidirectional type of messaging.
-there is guarantee of delivery.
When will u use a topic and when will u use a queue?
Answer: 1.only one producer and only one consumer is there then “Queues” are used. Simply “Queue” is of type “Point to Point”. One or more than one publishers and one or more than one subscriber is there than “Topic”. Simply “Topic” is of type “Broadcast messaging”.
Can queues be shared between two consumers?
Answer: Yes. If queue is non-exclusive (default) it can be shared by any number of consumers. Non-exclusive queues are useful for balancing the load of incoming messages across multiple receivers.
What is an exclusive queue? When would u use it?
Answer: If queue is exclusive, then all queue messages can only be retrieved by the first consumer specified for the queue. Exclusive queues are useful when we want only one application to receive messages for a specific queue.
A message in a queue can be consumed by how many consumers?
Answer: if all are non-exclusive queue any number of consumers will receive messages. If exclusive queue, the first consumer will get messages.
How will you grant privileges to topics and queues?
Answer: Only EMS admin have privilege
What are the protocols supported by JMS/EMS?
Answer: 1.SSL (HTTP) 2. TCP

What are the limitations of the Durable Subscriber?

As long as the durable subscriber exists
• Expiration time of the message
• Storage limit of that Topic

What is the difference between “Multicasting” and “publish and subscribe” messaging model?

BROADCAST-
Many publishers can publish to the same topic, and a message from a single publisher can be received by many subscribers. Subscribers subscribe to topics,
and all messages published to the topic are received by all subscribers to the topic.This type of message protocol is also known a broadcast messaging because
messages are sent over the network and received by all interested subscribers,similar to how radio or television signals are broadcast and received.

MULTICAST-
Multicast messaging allows one message producer to send a message to multiple subscribed consumers simultaneously.It is similar to publish and subscribe in that it
also addresses message to a topic. Instead of delivering a copy of the message to each individual subscriber over TCP,however, the EMS server broadcasts the message
over Pragmatic General Multicast (PGM). A daemon running on the machine with the subscribed EMS client receives the multicast message and delivers it to the message
consumer.
Multicast is highly scalable because of the reduction in bandwidth used to broadcast messages & it also uses less EMS resources.
However,one drawback of this model is that it does not guarantee the delivery of messages to all subscribers.

What are the EMS Destination features?
• Secure Property
• Trace Property
• Store Property
• Redelivery policy
• Flow control
• Exclusive property for queues

What are the extra features are available in EMS apart from JMS?

The JMS standard specifies two delivery modes for messages, PERSISTENT and NON_PERSISTENT. EMS also includes a RELIABLE_DELIVERY mode that eliminates some of the overhead associated with the other delivery modes.
• For consumer sessions, you can specify a NO_ACKNOWLEDGE mode so that consumers do not need to acknowledge receipt of messages, if desired. EMS also provides an EXPLICIT_CLIENT_ACKNOWLEDGE and EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE mode that restricts the acknowledgement to single messages
• EMS extends the MapMessage and StreamMessage body types. These extensions allow EMS to exchange messages with TIBCO Rendezvous and ActiveEnterprise formats that have certain features not available within the JMS MapMessage and StreamMessage

What is structure of JMS Message?

Header(Required)
• Properties(optional)
• Body(optional)

Where does the undelivered messages will be stored?

If a message expires or has exceeded the value specified by the maxRedelivery property on a queue, the server checks the message’s JMS_TIBCO_PRESERVE_UNDELIVERED property. If 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 cannot be deleted. If JMS_TIBCO_PRESERVE_UNDELIVERED is set to false, the message will be deleted by the server
• You can only set the undelivered property on individual messages, there is no way to set the undelivered message queue as an option at the per-topic or per-queue level

What are the messages bodies are supported by the EMS?
• Map Message
• Text Message
• Stream Message
• Bytes Message
• Object Message

What is the Maximum message size is supported by EMS?

EMS supports messages up to a maximum size of 512MB. However, we recommend that application programs use smaller messages, since messages approaching this maximum size will strain the performance limits of most current hardware and operating system platforms

What are the different delivery modes available in EMS?

Persistent
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

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

Reliable
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.
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.

If a persistent message is published on to a TOPIC, Does these messages will store on disk if topic doesn’t have durable subscriber or subscriber with a fault-tolerant connection?
No. 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

What are the different types of acknowledgement modes in EMS message delivery?
• Auto
• Client
• Dups_ok
• No_ack
• Explciit
• Explicit_client_dups_ok
• Transitional
• Local transitional.

What are the different types of messages that can be used in EMS
• Text
• Simple
• Bytes
• Map
• XML test
• Object
• Object ref
• Stream

Tell me about bridges. Why do we use them, Syntax to create bridges, use of message selector?
• Some applications require the same message to be sent to more than one destination possibly of different types. So we use bridges in that scenario.
• create bridge source=type:dest_name target=type:dest_name [selector=selector]

What is the purpose for stores.conf

This file defines the locations either store files or a database, where the EMS server will store messages or metadata. Each store configured is either a file-based or a database store.

How many modes are the messages written to store file.
• Two Modes: Synchronous and Asynchronous
• Default is asynchronous

What is tibemsd.conf
• It is the main configuration file that controls the characteristics of the EMS server

Name destination properties and explain them.
• Global, secure, maxmsgs, maxbytes, flowcontrol, sender_name, sender_name_enforced, trace,maxRedelivery

What are the different modes of installation in Ems?
• GUI mode
• Console mode
• Silent mode

What are the messaging models supported by JMS
• Point-to-point
• Publish-subscribe
• Multicast
What is the use of routes? What kind of destinations can be used in routes?
• Topics and queues m-hops

What happens if the message expires/exceeded the value specified by maxredelivery property on queue?
• If the jms_preserve_undelivered property is set to true, then it moves he message to undelivered message queue, if set to false, the message is deleted by the server.

In how many ways can a destination be created?
• Static-created by server
• Dynamic-created by client
• Temporary destinations.

What are the wild cards that we use in ems? how do they work for queues and topics
• *,> you can subscribe to wildcard topics but can’t publish to them. Where as in case of queues we can’t either send /receive.

Is bridges are transitive?
• NO

What Are flow control on destinations
• Some times the producer may send messages faster than the consumers can receive them. So, the message capacity on the server will be exhausted. So we use flow control. Flow control can be specified on destinations.

What Are flow control on bridges and routes
• Flow control has to be specified on both sides of bridges where as on routes it operates differently on sender side and receiver side.

What are the permissions that you can grant to users to access queues
• Receive
• Send
• Browse
What are the permissions that you can grant to users to access topics
• Subscribe
• Publish
• Durable
• Use_durable

Tell me about multicasting in EMS
• Multicast is a messaging model that broadcasts messages to many consumers at once rather than sending messages individually to each consumer. EMS uses Pragmatic general multicast to broadcast messages published to multicast enabled topics.
• Each multicast enabled topic is associated with a channel.

What are the advantages and disadvantages of multicasting?
• Advantages: as the message broadcasts only once thereby reducing the amount of bandwidth used in publish and subscribe model. Reduces the network traffic.
• Disadvantages: Offers only last-hop delivery. So can’t be used to send messages between servers.

On what destinations can you use multicast?
• Topics

Suppose, you got an error while accessing a queue, that you don’t have necessary permissions to access the queue. What might be the solution/reason?
• The user that is assigned to the queue and the user used while creating

How does the secondary server know that the primary server is failed?
• Based on heartbeat intervals

What is JMS queue requestor?
• The JMS Queue Requestor activity is used to send a request to a JMS queue name and receive a response back from the JMS client

What is JMS topic requestor?
• The JMS Topic Requestor activity is used to communicate with a JMS application’s request-response service. This service invokes an operation with input and output. The request is sent to a JMS topic and the JMS application returns the response to the request.

How do you add ems server to administrator?
• Using domain utility

How do you remove individual messages from destinations?
• Use Purge Command.

What are the messaging models does EMS support?
• Point-to-Point (Queue)
• Publish and Subscribe (Topic)
• Multicast (Topic)

What are the limitations of the Durable Subscriber?
• As long as the durable subscriber exists
• Expiration time of the message
• Storage limit of that Topic

What are the EMS Destination features?
• Secure Property
• Trace Property
• Store Property
• Redelivery policy
• Flow control
• Exclusive property for queues

What are the extra features are available in EMS apart from JMS?
• The JMS standard specifies two delivery modes for messages, PERSISTENT and NON_PERSISTENT. EMS also includes a RELIABLE_DELIVERY mode that eliminates some of the overhead associated with the other delivery modes.
For consumer sessions, you can specify a NO_ACKNOWLEDGE mode so that consumers do not need to acknowledge receipt of messages, if desired. EMS also provides an EXPLICIT_CLIENT_ACKNOWLEDGE and EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE mode that restricts the acknowledgement to single messages
• EMS extends the MapMessage and StreamMessage body types. These extensions allow EMS to exchange messages with TIBCO Rendezvous and ActiveEnterprise formats that have certain features not available within the JMS MapMessage and StreamMessage

What is structure of JMS Message?
• Header(Required)
• Properties(optional)
• Body(optional)

Where does the undelivered messages will be stored?
• If a message expires or has exceeded the value specified by the maxRedelivery property on a queue, the server checks the message’s JMS_TIBCO_PRESERVE_UNDELIVERED property. If 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 cannot be deleted. If JMS_TIBCO_PRESERVE_UNDELIVERED is set to false, the message will be deleted by the server
• You can only set the undelivered property on individual messages, there is no way to set the undelivered message queue as an option at the per-topic or per-queue level

What is the Maximum message size is supported by EMS?
• EMS supports messages up to a maximum size of 512MB. However, we recommend that application programs use smaller messages, since messages approaching this maximum size will strain the performance limits of most current hardware and operating system platforms

TIBCO EMS – No memory for operation – Filesystem as datastore.

Very often we come across this kind of an error :-

Most probably if your EMS is running as a 32bit Binary and your message size is exceeding 1.6 – 2 GB in size

EMS For 32 bit has a size limitation of 2 GB

When you are using Filesystem as a datastore,

and when you come across such a trace

2007-07-24 10:46:38 Recovering state, please wait.
2007-07-24 10:48:47 SEVERE ERROR: Failed writing message to ‘datastore/meta.db’: No memory for operation.
2007-07-24 10:48:50 SEVERE ERROR: No memory processing purge record.
2007-07-24 10:48:52 FATAL: Exception in startup, exiting.

434692644 Jul 24 11:16 meta.db
29220 Jul 24 08:54 sync-msgs.db
5805854244 Jul 24 08:37 async-msgs.db

Don’t Panic, Its a very Generic issue

Just follow these checklists

  1. Size of your message
  2. Ensure you are using 64 bit EMS binary
  3. Set max_msg_memory= <XX>GB in your tibemsd.conf, where XX indicated the Memory in GB you wanna assign.
  4. Set msg_swapping=enabled.
  • max_msg_memory

max_msg_memory = size [KB|MB|GB]
Maximum memory the server can use for messages.
This parameter lets you limit the memory that the server uses for messages, so server memory usage cannot grow beyond the system’s memory capacity.
When msg_swapping is enabled, and messages overflow this limit, the server begins to swap messages from process memory to disk. Swapping allows the server to free process memory for incoming messages, and to process message volume in excess of this limit.
When the server swaps a message to disk, a small record of the swapped message remains in memory. If all messages are swapped out to disk, and their remains still exceed this memory limit, then the server has no room for new incoming messages. The server stops accepting new messages, and send calls in message producers result in an error. (This situation probably indicates either a very low value for this parameter, or a very high message volume.)
Specify units as KB, MB or GB. The minimum value is 8 MB. The default value of 0 (zero) indicates no limit.
For example:
max_msg_memory = 512MB

msg_swapping

msg_swapping = enable | disable
This parameter enables and disables the message swapping feature (described above for max_msg_memory).
The default value is enabled, unless you explicitly set it to disabled.

reserve_memory

reserve_memory = size
When reserve_memory is non-zero, the daemon allocates a block of memory for use in emergency situations to prevent the EMS server from being unstable in low memory situations. When the daemon process exhausts memory resources, it disables clients and routes from producing new messages, and frees this block of memory to allow consumers to continue operation (which tends to free memory).
The EMS server attempts to reallocate its reserve memory once the number of pending messages in the server has dropped to 10% of the number of pending messages that were in the server when it experienced the allocation error. If the server successfully reallocates memory, it begins accepting new messages.
The reserve_memory parameter only triggers when the EMS server has run out of memory and therefore is a reactive mechanism. The appropriate administrative action when an EMS server has triggered release of reserve memory is to drain the majority of the messages by consuming them and then to stop and restart the EMS server. This allows the operating system to reclaim all the virtual memory resources that have been consumed by the EMS server. A trace option, MEMORY, is also available to help show what the server is doing during the period when it is not accepting messages.
Specify size in units of MB. When non-zero, the minimum block is 16MB. When absent, the default is zero.

TIBCO – EMS – Multicasting

Multicast Messaging:  Multicast is a messaging model that allows the EMS server to send messages to multiple consumers simultaneously by broadcasting them over an existing network.

Overview:
  Multicast is a messaging model that broadcasts messages to many consumers at once, as opposed to sending copies of a message to each subscribing consumer individually.

The server sends multicast messages over a multicast channel. Each multicast-enabled topic is associated with a channel. The channel determines the multicast port and multicast group address to which the server sends messages.

The multicast message is received by a multicast daemon running on the same computer with the message consumer.

When an EMS client subscribes to a multicast-enabled topic, it automatically connects to the multicast daemon. The multicast daemon begins listening on the channel associated with that topic, receives any broadcast messages, and delivers them to subscribed clients.

When to use Multicast:
  Because multicast reduces the number of operations performed by the server and
reduces the amount of bandwidth used in the publish-and-subscribe model, multicast is highly scalable.

Where publish and subscribe messaging creates a copy of a published message for each message consumer, multicast broadcasts the message only once.

sample Pictures

Features

Multicast is highly scalable
Multicast reduces the amount of bandwidth consumed
Multicast reduces the number of operations performed by the server
Multicast broadcasts the message only once, where as in case of publish and subscribe for each of the consumer a copy of the message is getting published

Facts

Multicast does not guarantee message delivery
Messages requiring a high degree of reliability should not use multicast
Multicast offers last-hop delivery only; it cannot be used to send messages between servers.
Multicast should not be used in applications where security is a priority

 

Multicast Messaging Example:

Multicast channels can only be configured statically by modifying the configuration files. There are no commands in the administration tool to configure multicast channels.

 

Step 1: Enable the EMS Server for Multicast

To enable multicast in the server, set the multicast property to enabled in the tibemsd.conf configuration file:
multicast = enabled

 

Step2: Create a Multicast Channel

The EMS server broadcasts messages to consumers over multicast channels. Each channel has a defined multicast address and port. Messages published to a multicast-enabled topic are sent by the server and received by the subscribers on these multicast channels.
To create a multicast channel, add the following definition to the multicast channels configuration file, channels.conf:
[multicast-1]
address=234.5.6.7:1

 

Start the EMS Server.

 

Step3: Create a topic with Multicast enabled 

To create a multicast-enabled topic, use the administration tool to issue the following command:


> create topic testtopic channel=multicast-1

 

then execute the show topic command to verify multicast is enabled or not

 >show topics

 

the result will be like …

 

Topic Name SNFGEIBCTM Subs Durs Msgs Size

testtopic                  ———+           0 0 0 0.0 Kb

 

+ at M means multicast is enabled.

 

Step 4: Start the Multicast Daemon

go to Start menu, follow the path All Programs > TIBCO > TIBCO EMS 7.0 > Start
EMS Multicast Daemon.

 

Step5: Start the Subscriber

Execute the tibjmsMsgConsumer client to assign user1 as a subscriber to the multicastTopic topic with a Session acknowledgment mode of NO_ACKNOWLEDGE:
C:\tibco\ems\7.0\samples\java> java tibjmsMsgConsumer –topic testtopic –user user1 –ackmode NO

in Administration Console type the below command for cross verification…

>show consumers topic=testtopic

 

Step6: Start the producer

 Setting up a client to publish multicast message is no different from setting up a client to send publish and subscribe messages. Because the topic is enabled for multicast in the EMS server, the message producer does not need to follow any additional steps.

 

C:\tibco\ems\7.0\samples\java>java tibjmsMsgProducer -topic testtopic -user admin hello

 

Finally the messages (hello) is displayed in the subscriber’s window.

 

[ERROR]-[Enterprise Message Service]-What is the meaning of the following error: “ERROR: Slow clock tick xxx, delayed messaging and timeouts may occur”?

Capture

The error message “Slow clock tick xx, delayed messaging and timeouts may occur” was added in EMS 5.1.4 for defect #1-A35PT9 -The server can disconnect clients or other servers if it gets very busy such that it does not service incoming heartbeats within the server_timeout_client_connection or server_timeout_server_connection period.

The number xx indicates the delay when the timer thread is behind the current time, indicating that the EMS server has become busy.

The value of xx is the time difference in seconds.

This is an Informational message and is not detrimental to EMS, rather it is an indication that the EMS server is busy and delayed messaging and timeouts may occur.

Fault Tolerance Parameters in “tibemsd.conf ” file

ft_active

 
ft_active = URL
 
Specifies the URL of the active server.
If this server can connect to the active server, it will act as a backup server.
If this server cannot connect to the active server, it will become the active server.
ft_heartbeat
 
ft_heartbeat = seconds
 
Specifies the interval (in seconds) the active server is to send a heartbeat signal to the backup server to indicate that it is still operating. Default is 3 seconds.
ft_activation
 
ft_activation = seconds
Activation interval (maximum length of time between heartbeat signals) which indicates that active server has failed. Set in seconds: default is 10.
This interval should be set to at least twice the heartbeat interval.
For example: ft_activation = 60
Note: The ft_activation parameter is only used by the backup server after a fault-tolerant switchover.
The active server uses the server_timeout_server_connection to detect a failed server.
ft_reconnect_timeout
 
ft_reconnect_timeout = seconds
The amount of time (in seconds) that a backup server waits for clients to reconnect (after it assumes the role of primary server in a failover situation).
If a client does not reconnect within this time period, the server removes its state from the shared state files.
The ft_reconnect_timeout time starts once the server has fully recovered the shared state, so this value does not account for the time it takes to recover the store files.
The default value of this parameter is 60.

TIBCO EMS – Administration Commands (Some Important Ones)

Create User: create a new user
syntex : create user <user name> [“user_description”] [password=<password>]
example: create user test “Test user” password=test

Show Users: Show all users
syntex : show users
example: show users

Delete user: delete the named user
syntax : delete user <user name>
example: delete user test

Create group: creates a new group of users. Initially the group is empty. You need to add users in the group.
syntax : create group group_name “description”
example: create group Training “Training group”

Delete group: delete the named group
syntax : delete group <group name>
example: delete group training

Add member: Add one or more users to the group
syntax : add member <group name> <user name>, <user name> …
example: add member training  test

Set password: Set the password for the named user
syntax : set password <user-name> [password]
example: set password test 123

Grant admin : Grant the named global administrator permissions to the named user or group. For a complete listing of global administrator permissions
syntax : grant admin user=<user name> | group=<group name> <admin_permissions>
example: grant admin user=test all
grant admin group=training all
Note: some admin permissions: all:- all admin permissions, change-connection:-delete connection

Connect: Connect the administrative tool to the server
syntax : connect tcp://<server name>:<port number>
example: connect tcp://server2000:7222

Disconnect: Disconnect the administrative tool from the server
syntax : disconnect
example: disconnect

create topic : Creates a topic with specified name and properties. Properties are listed in a
comma-separated list, as described in topics.conf . You can set the properties directly in the topics.conf
or by means of the setprop topic command in the EMS Administrator Tool.
syntax : create topic <topic_name> <[properties]>
example: create topic t1

Show Topic : Shows the details for the specified topic
syntax : show topic <topic-name>
example: show topic t1

setprop topic : Set topic properties, overriding any existing properties
syntax : setprop topic <topic-name> <properties>
example: setprop topic t1 secure,sender_name

addprop topic : Adds properties to the topic. Property names are separated by commas
syntax : addprop topic <topic_name> <properties,…>
example: addprop topic t1 failsafe

Grant topic : Grants specified permissions to specified user or group on specified topic. Multiple permissions are separated by commas.
Topic permissions are: subscribe, publish, durable, use_durable
Destination-level administrator permissions can also be granted with this command. The following are administrator permissions
for topics are – view , create , delete, modify , purge
syntax : grant topic <topic-name> <user=name | group=name> <permissions>
Note: The best way to define permissions on topic is-open acl.conf and modify in the file
example: TOPIC=t1 USER=user1 PERM=publish,subscribe,view

purge topic :  Purge all messages for all subscribers on the named topic
syntax : purge topic <topic-name>
example: purge topic t1

delete topic : delete specefic topic
syntax : delete topic <topic-name >
example: delete topic t1

create queue : Creates a queue with the specified name and properties. The possible queue properties are described in
Destination Properties. Properties are listed in a comma-separated list, as described in queues.conf. You can set the
properties directly in the queues.conf or by means of the setprop queue command in the EMS Administrator Tool.
syntax : create queue <queue_name> <[properties]>
example: create queue q1

Show Queue : Shows the details for the specified queue
syntax : show queue <queue-name>
example: show queue q1

setprop queue : Set queue properties, overriding any existing properties. Any properties on a topic that are not explicitly specified by this command are removed
syntax : setprop queue <queue-name> <properties>
example: setprop queue q1 secure,sender_name

addprop queue : Adds properties to the queue. Property names are separated by commas
syntax : addprop queue <topic_name> <properties,…>
example: addprop queue q1 failsafe

Grant queue : Grants specified permissions to specified user or group on specified queue. Multiple permissions are separated by commas
Queue permissions are: receive, send, browse
Destination-level administrator permissions can also be granted with this command. The following are administrator permissions
for queue are – view , create , delete, modify , purge
syntax : grant queue <queue-name> <user=name | group=name> <permissions>
Note: The best way to define permissions on queue is-open acl.conf and modify in the file
example: QUEUE=q1 USER=user1 PERM=receive,browse

purge queue : Purge all messages in the named queue
syntax : purge queue <queue-name>
example: purge queue q1

delete queue : delete specefic queue
syntax : delete queue <topic-name >
example: delete queue t1

Create durable : Creates s static durable subscriber
syntax : create durable <topic name> <durable name> [property,….,property]
example: create durable t1 durable1
Note: why durable: By default, subscribers only receive messages when they are active. If messages arrive on the topic
when the subscriber is not available, the subscriber does not receive those messages.
The EMS APIs allow you to create durable subscribers to ensure that messages are received, even if the message consumer
is not currently running. Messages for durable subscriptions are stored on the server as long as durable subscribers exist
for the topic, or until the message expiration time for the message has been reached, or until the storage limit has been
reached for the topic. Durable subscribers can receive messages from a durable subscription even if the subscriber was not
available when the message was originally delivered.When an application restarts and recreates a durable subscriber with the
same ID, all messages stored on the server for that topic are published to the durable subscriber.

Delete durable : Delete the named durable subscriber
syntax : delete durable <durable-name>
example: delete durable durable1

Show config: Shows the configuration parameters for the connected server
syntax : show config

Show consumer or show consumers: information about a specific consumer or all consumers
syntax : show consumer <consumer id> or show consumers
example: show consumer 6 or show consmers

show connections : Show connections between clients and server
syntax: show connections [type=q|t|s] [host=hostname] [user=username] [version] [address] [counts] [full]
example: show connections

show db : Print a summary of the server’s databases
syntax : show db [sync|async]
example: show db