EMS

Synchronous or Asynchronous Message Consumption

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 listeners onMessage() method

Flow Control
In some situations, message producers may send messages more rapidly than
message consumers can receive them. The pending messages for a destination are
stored by the server until they can be delivered, and the server can potentially
exhaust its storage capacity if the message consumers do not receive messages
quickly enough. To avoid this, TIBCO Enterprise Message Service allows you to
control the flow of messages to a destination. Each destination can specify a target
maximum size for storing pending messages. When the target is reached, TIBCO
Enterprise Message Service blocks message producers when new messages are
sent. This effectively slows down message producers until the message consumers
can receive the pending messages.
Enabling Flow Control
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. See Chapter 7, Using the Configuration
Files, on page 117 for more information about working with configuration
parameters.
When you wish to control the flow of messages on a destination, set the
flowControl property on that destination. The flowControl property specifies the
target maximum size of stored pending messages for the destination. The size
specified is in bytes, unless you specify the units for the size. You can specify KB,
MB, or GB for the units. For example, flowControl = 60MB specifies the target
maximum storage for pending messages for a destination is 60 Megabytes.
Enforcing Flow Control
The value specified for the flowControl property on a destination is a target
maximum for pending message storage. When flow control is enabled, the server
may use slightly more or less storage before enforcing flow control, depending
upon message size, number of message producers, and other factors. Setting the
flowControl property on a destination but specifying no value causes the server to
use a default value of 256KB.

Configuring 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 the backup 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.

What is PointToPoint and Publish/Subscribe model

What are exclusive queues and what are non-exclusive queues?

Point-to-point messaging has one producer and one consumer per message.
This style of messaging uses a queue to store messages until they are
received. The message producer sends the message to the queue; the
message consumer retrieves messages from the queue and sends
acknowledgement that the message was received.
More than one producer can send messages to the same queue, and more than one
consumer can retrieve messages from the same queue. The queue can be
configured to be exclusive, if desired. If the queue is exclusive, then all queue
messages can only be retrieved by the first consumer specified for the queue.
Exclusive queues are useful when you want only one application to receive
messages for a specific queue. If the queue is not exclusive, any number of
receivers can retrieve messages from the queue. Non-exclusive queues are useful
for balancing the load of incoming messages across multiple receivers. Regardless
of whether the queue is exclusive or not, only one consumer can ever retrieve each
message that is placed on the queue

In a publish and subscribe message system, producers address messages to

a topic. In this model, the producer is known as a publisher and the
consumer is known as a subscriber.
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 as
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.
Q

What is Static and Dynamic Queue in EMS Compare them

Configuration information for static queues and topics is stored in configuration

files for the TIBCO Enterprise Message Service server. 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, you can use
the administration tool, or you can use the administration APIs. Static queues and
topics are administered by the server. Clients retrieve the destination using JNDI.
Dynamic

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.

queues

and

What are the delivery modes available in EMS?

TIBCO Enterprise Message Service provides two modes for persisting

topic/queue messages in external storage. These two modes are:

normal

failsafe

Normal mode writes all messages into the file on disk in asynchronous
mode. In this mode, the data may remain in system buffers for a short time
before it is written to disk.

For situations in which any loss of data is not acceptable, the administrator
should set the failsafe property for the topic or the queue. 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. Although failsafe mode guarantees no messages are lost, it also
significantly affects the performance.

What are durable subscribers?

There can be a time dependency in publish and subscribe mode. By default,

subscribers only receive messages when they are active. If messages are delivered
when the subscriber is not available, the subscriber does not receive those
messages. The JMS API provides a method to remove part of the timing
dependency by allowing subscribers to create durable subscriptions. Messages for
durable subscriptions are stored on the server until the message expires or the
storage limit is reached. Subscribers can receive messages from a durable
subscription even if the subscriber was not available when the message was
originally delivered.

What are destination bridges?

Destination Bridges
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.
An application can process messages so that they are sent multiple times to the
required destinations. However, such processing requires significant coding effort
in the application. TIBCO Enterprise Message Service provides a server-based

solution to this problem. 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. You can also create a bridge between one
destination and multiple destinations. For example, you can create a bridge from
topic a.b to queue q.b and topic a.c. When specifying a bridge, you can specify a
particular destination name, or you can use wildcards. For example, if you specify
a bridge on topic foo.* to queue foo.queue, messages delivered to any topic
matching foo.* are sent to
foo.queue.

What is the disadvantage of using foreign JNDI provider in EMS?

Routing
Each route connects two TIBCO Enterprise Message Service servers.
Each route forwards messages between corresponding destinations (that
is, global topics with the same name, or explicitly routed queues) on its two
servers.
Routes are bidirectional; that is, each server in the pair forwards messages
along the route to the other server

A zone is a named set of routes. Every route belongs to a zone. A zone

affects the forwarding behavior of its routes:
In a multi-hop (mhop) zone, topic messages travel along all applicable
routes to all servers connected by routes within the zone.
In a one-hop (1hop) zone, topic messages travel only one hop (from the
first server).
Queue messages travel only one hop, even within multi-hop zones.

With respect to routing, queues differ from topics in several respects:

 Servers route queue messages between the queue owner and adjacent
servers.
The concept of zones and hops does not apply to queue messages (only to
topic messages).

JMS
Wire Formats Supported by JMS:
1) XML Message
Connection Factory Type Supported by JMS:
1)Topic
2)Queue
Delivery Mode Supported by JMS:
1) Persistent
2) Non-Persistent
Posted by Arun at 1:12 AM 0 comments

Labels: TIBCO Adapters FAQ'S

TIBCO EMS FAQ'S
EMS
What are the different modes of installation in Ems?
a. GUI mode
b. Console mode
c. Silent mode
What are the messaging models supported by JMS?
a. Point-to-point
b. Publish-subscribe
c. Multicast
What are the destinations in EMS/JMS and their differences?
Ans:
Queues: point-point communication. Any number of producers and consumers can
exist. At any time and situation each message is taken by only one consumer.
Exclusive: only the first consumer who picks up the first message can take the rest
of the messages (used if u wants only one consumer).
Non-exclusive: where any number of consumers can exist. Used for load balancing.
Topics: publish-subscribe.

Any number of publishers and subscribers can exist. Each message can be taken by
any number of consumers (radio).
In how many ways can a destination be created?
a. Static-created by user
b. Dynamic-created by ems server on the fly.
c. Temporary destinations.
Queues Vs Topics in TIBCO EMS
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-ofservices 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 Relationship between Temporary queue, queue, destination.
A Destination can be a Queue or Topic, which typically says static. Which means you
physically create this queue.
I hope you know the definition for Queue which can static, dynamic or temporary.
Static represents physical creation.
Dynamic Represents, which will be created by receiver/sender application at run
time, life span is limited, as long as there is messages or receivers, it will stay in
server, if not it deletes.
Temporary Queue means, created by receiver to submit the response to EMS server
or Sender to get the messages. this life span is immediate, but there is a hidden
danger with these queues, as these might turn into orphan queues (please read

other articles). there is a fix, which will go by 4.4.2 ems version

Difference between Exclusive and Non Exclusive Queues
you can define a queue as exclusive to make sure that all the messages are always
sent to the same consumer, even if you have more than one connected to it. If you
make it exclusive the rest of the consumers are "on standby" so if the primary fails
another one is set as primary and starts receiving.
If you set them to non-exclusive (the default value) and you have more than one
consumer connected to the queue the messages are delivered in a round robin
fashion to balance the load.
What is the use of system queues?
system queues are undeleteable queues stored usualy undelivered messages (when
you set JMS_TIBCO_PRESERVE_UNDELIVERED to true, in case the message exipres,
you'll get it to $sys.undelivered) or other even driven messages if applicable.
More in use are sytem topics for monitoring and statistics, where is EMS publishing
queue and server statistics and can be detailed to message content level.
dead Queue
In case of any failures in the messages to server, will be added to dead queue,
which is kind of internal system queue, I strongly feel.
For ex: No memory trying to add message to dead queue.
Failure queuing message to add to dead queue
How do we distinguish dynamic queues with static queues?
Ans: dynamic queues have * before them.
what are the message storing mechanisms of queues?
Ans: persistent and non-persistent.
Persistent: messages are stored to external storage before sending.
Non-persistent: not stored to any external storage. The information will not be
available for retrieval.
what are types of subscribers we can have for topics? Explain them in detail.
Ans: durable and non-durable subscribers.
In durable subscriptions the messages are stored so that even if the subscriber fails
and comes back the messages can be retrieved.
What are the permissions that you can grant to users to access queues?
a. Receive
b. Send
c. Browse

What are the permissions that you can grant to users to access topics?
a. Subscribe
b. Publish
c. Durable
d. Use_durable
What is the difference between Queues and Topics?
Queue
Guaranteed Service
Only the Target gets the message (One message per Consumer)
Uses Peer-to-Peer Mode to deliver messages
Blocking
Load Balancing is possible
Topic
Reliable Service
Everyone active gets the message (One message may Consumers)
Uses Pub / Sub mode to deliver messages
Non-Blocking
Load Balancing is not Possible
What is the use of secured queues and topics?
Setting secure property to queues/topics can restrict unauthorized users from
publishing/sending and subscribing/receiving the messages.

What are acknowledgement modes and where do you set them and what is the
applicability of each mode?
Ans:The acknowledge mode for incoming messages. Can be one of the following:
Auto the message is automatically acknowledged when it is received.
Client the message will be acknowledged at a later point by using the Confirm
activity. If the message is not
confirmed before the process instance ends, the message is redelivered and a new
process instance is
created to handle the new incoming message. Ensure that your process definition
confirms the message
when using this acknowledge mode .
TIBCO EMS Explicit Client Acknowledge this mode behaves exactly the same as
the Client mode, except the
session is not blocked and one session can handle all incoming messages
Dups OK the message is acknowledged automatically when it is received. JMS
provides this mode for lazy

acknowledgement, but TIBCO BusinessWorks acknowledges messages upon receipt.

Transactional this mode is used when a transaction that can process JMS
messages is included in the process
definition. The message is acknowledged when the transaction commits.
what is the structure of messages in JMS?
Ans: header(needed),
properties(optional)
body(optional).
Header parameters:
JMS destination,
JMS message.
What is the purpose of JMS Queue receiver activity and Queue sender activity?
Ans: Starts a process when ever a new message comes into the specified queue.
A queue sender activity sends messages into the specified queue.
What is the potential problem with JMS Queue requestor?
Ans: When we specify a reply to queue there is a chance of other processes sending
messages to the same queue
and the jms queue requestor interpreting that as the actual response and sending
this wrong message to the client.
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 applications
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 to setup load balancing for Topics and queues?
Ans: We can achieve load balancing using bridging queues and topics.
Or Queues can be set non-exclusive so that any number of consumers can access
the queue.
What are the different levels of load balancing in EMS and how would you do it?
Ans: server level and consumer level
Server: by having multiple servers.
Consumer: by creating consumer instances.

What are the differences between server load balancing & producer/consumer load
balancing?
Point-to-Point : Non-exclusive queues are useful for balancing the load of incoming
messages across multiple receivers.
Programs can use distributed queues for one-of-n certified delivery to a group of
servers, in order to balance the load among the servers.
Rendezvous distributed queue software assigns each task to exactly one of the
servers, while the group of servers and the distribution of tasks remains completely
transparent to the client processes.
EMS Load balancing can be done in only one way on the consumer side, by using
multiple subscribers/receivers to a same topic/queue, and which will be executed in
round robin fashion. If we are connecting two different severs by using "|" symbol is
not be load balancing, Consumers can not switch connections between two servers.
By default, we will implement multiple consumers but we have to consider above
mentioned issues in consumer load balancing.

How would you do fault-tolerance in EMS? Explain the complete process.

Ans: FT in EMS can be achieved by implementing pair of servers called primary and
backup while the primary does the normal job of sending and receiving messages
the back up server takes the place of primary if the primary fails. The pair shares
the information from the shared state. When the primary goes down the backup
server reads all the primary config files and starts from there. The primary locks the
shared state if its active so that the backup server doesnt take its place. the lock is
released when the primary goes down so that the backup can lock the shared state.
Only persistent messages can be implemented in this situation since non-persistent
messages cannot be stored in external storage like shared state.
How a consumer can connect to the new primary EMS server when the running
primary server goes down?
Ans: we can specify multiple URLS for the client so that if the primary is down the
next URL belonging to back up will be used.
In case of a primary having multiple address we can use multiple URLS for the
same server so that even the primary in one location is down it can connect to the
primary of another location.
The URLS are usually comma separated in client config.
How the clients of the primary server access the messages stored by primary server
when it goes down and secondary server becomes primary server?
Ans: clients can be config to be intimated of the failover.
The backup reads the current state of the client from the shared storage

And then connects to the client if there are any undelivered persistent messages.
Scenario: Topic T1, Queue Q1 and Queue Q3 are bridged. A publisher published a
message to Topic T1. But the publisher has no access rights to Q1. How the
message will be traversed?
Ans: 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.
Scenario: A publisher is publishing messages quickly than the consumers are
consuming the messages. How to control this situation.
Ans: we can use flow control to address this situation. The target maximum size for
pending messages is specified so that only that amount of message is stored and
any messages above that will be blocked.
The server blocks the send call and releases only when the storage limit is below
the set value.
The flow control is enabled only if the topic or queue has receivers.
This way the producers are slowed down. And the balance is achieved.
Can we set a limit for the total number of pending messages on Queue or Topic?
What is the parameter for that
Ans: yes, max-bytes for pending messages.
What if max-bytes limit exceeds?
Ans: Messages that would exceed the limit will not be accepted into storage and an
error is returned to the message producer.
What is the pre-fetch value?
Ans: In order for reducing the clients waiting time in a server client scenario
For a queue based messaging only the prefetch value allows the the server to send
messages in batches so that the message will be ready for the client when ever the
client is ready. For automatic fetching its >1 and for disabling its none.
What is fail-safe?
Ans: The Tibco ems provides 2 modes for persistent topic/queue message storing to
external device.
Normal: in this mode the messages stay in a buffer before writing to a storage(disk).
So in case of any failure the messages may be lost.This mode is very efficient in
situations were little loss of data is allowed.
Failsafe: in the fail safe mode the messages are first written to an external storage
before sending so that no messages are lost ever. This is used when no loss of data
can be encouraged.

How many ways we can determine the life span of the message in a queue. What
are they?
Ans: Expiration parameter in queue configuration file.
JMS expiration time in queue sender.
The JMS expiration time in queue sender overrides any value given in config.
What are the basic configuration you would setup if you want to enable your EMS
server for SSl communication
Ans: listen parameter and ssl_server_identity. Optionally private key.
What is the main config file in JMS?
Ans: The main configuration file controls the characteristics of the TIBCO Enterprise
Message Service server. This file is usually named tibemsd.conf, but you can specify
another file name when starting the server.
Exp para: server, password,flowcontrol,storage,server sartup
Can you send messages from a server to another server?
TIBCO Enterprise Message Service servers can route messages to other servers.
Topic messages can travel one hop or multiple hops(from the first server).
Queue messages can travel only one hop to the home queue, and one hop from
the home queue.
A server forwards topic messages along routes only when the global property is
defined for the topic.
When a route becomes disconnected (for example, because of network problems),
the forwarding server stores topic messages. When the route reconnects, the server
forwards the stored messages.
What are multi-hop zone?
Ans: Multi-hop zone is a group of servers connected by routes.
How do you configure multi-hop zones?
By using routes
To create a route using the administration tool, first connect to one of the servers,
then use the create route command with the following syntax:
create route url= zone_name= zone_type=1hop|mhop
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.
What is the purpose for stores.conf
a. This file defines the locations either store files or a database, where the EMS

server will store messages or

metadata
b. Each store configured is either a file-based or a database store.
How many modes are the messages written to store file.
2 modes.. sync or async. When absent , the default is async
What is tibemsd.conf
It is the main configuration file that controls the characteristics of the EMS server.
How many delivery modes for messages?
Persistent, Non-persistent, Reliable-delivery.
What is the maximum messagesize?
Ems supports max message size of 512 mb
Name 3 destination properties and explain them.
Global, secure, maxmsgs, maxbytes, flowcontrol, sender_name,
sender_name_enforced, trace, maxRedelivery
log_trace
"Log_Trace" writes information to the specified log file based on the trace options
logtrace will be written to log file.
Console_trace
Console Trace will be useful when you start your server in common window, and all
logs will be displayed there, and ofcourse it written to log files also when you
configure it.
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.
What are the wild cards that we use in ems?how do they work for queues and
topics?
*,>
We can subscribe to wildcard topics, but cant publish to them. Where as in case of
queues we cant either send /receive.
Are bridges transitive?
No
Tell me about 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.
Tell me about 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.
Name 3 configuration files and tell me what it consists of?
a. Queues.conf
b. Topics.conf
c. Routes.conf
d. Factories.conf
e. Stores.conf
f. Groups.conf, users.conf, transports.conf
Name some administrative level destination properties?
a. View
b. Create
c. Delete
d. Modify
e. Purge
How can you change the configuration properties of EMS server?
You can change in the tibemsd.conf file or you can change using the ems admin
console.
Tell me about multicasting in EMS?
a. 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.
b. Each multicast enabled topic is associated with a channel.
What are the advantages and disadvantages of multicasting..
a. Advantages: As the message broadcasts only once there by reducing the amount
of bandwidth used in publish and
subscribe model. Reduces the network traffic.
b. Disadvantages: Offers only last-hop delivery. So cant 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 dont 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
How do you add ems server to administrator?
Using domain utility
How do you remove individual messages from destinations?
Using purge command.
Connection and Session threading in Ems
Connection : Multi thread
Session : Single thread
Where do you use a bridge in real time?
we use in scenarios like publishing message from Topic to Queue, Store message in
EMS for retrieval in case if there is any problem while moving data from one process
to another.
When ever you are decided to use message selectors on BW, use bridges and use
message selector on bridges, which is more powerful than using message selectors
on BW.
What are the steps to perform Server Side Load Balancing on the local machine?
1. Make a duplicate copy of the cfgmgmt Folder and rename it to cfgmgmt2
2. Make sure that the Server Name is same in the tibemsd.conf file in both the
folders.
3. Change the port number in the second folders tibemsd.conf file (listen =
tcp://xxxx)
4. Start both copies of the servers from the command prompt (ex: C:\ ..
\ems\5.1\bin\tibemsd config
5. C:\ .. \cfgmgmt\ems\data\tibemsd.conf)
6. In TIBCO Designer, modify the JMS Connection Provide URL to contain both the
servers
( ex: tcp://localhost:7222 | tcp://localhost:7223)
What are the steps to setup Fault Tolerance servers on the local machine?
1. Make a duplicate copy of the cfgmgmt Folder and rename it to cfgmgmt2
2. Make sure that the Server Names and Listen ports are not the same in the
tibemsd.conf file in both the folders.
3. Change the port number in the tibemsd.conf file (i.e ft_active = listen port of
the other server) in both the

cfgmgmt folders.
4. Start both copies of the servers from the command prompt
(ex: C:\ .. \ems\5.1\bin\tibemsd config C:\ .. \cfgmgmt\ems\data\tibemsd.conf)
What is the use of Bridges?
Some applications require the same message to be sent to more than one
destination possibly of different types. So we use bridges
What is the syntax to create Bridges without Message Selector?
create bridge source=queue:bridgequeue target=topic:bridgetopic
What is the syntax to delete a bridge?
delete bridge source=queue:bridgequeue target=topic:bridgetopic
What is the syntax to create Bridges with Message Selector?
create bridge source=queue:bridgequeue target=topic:bridge topic
selector="keyword"
What is the use of Bridges and Routes?
Both are used to channel messages from senders to receivers. Bridge act as
connector between two different queue and Routes act as connector between
different server for sending message and receiving acknowledgement of delivery.
What are the steps required to create a Route between two Servers?
1. Make a duplicate copy of the cfgmgmt Folder and rename it to cfgmgmt2
2. Make sure that the Server Name is NOT the same in the tibemsd.conf file in
both the folders.
3. Change the port number in the second folders tibemsd.conf file (listen =
tcp://xxxx)
4. Set the routing property to enabled in the tibemsd.conf files in both the folders
open factories.conf under
cfgmgmt2 and change the settings for GeneralConnectionFactory,
QueueConnectionFactory and
TopicConnectionFactory URL to (tcp://xxxx)
5. Create Route on Server 1 (route Server2-Name url=tcp://localhost:xxxx)
6. Create global queue / topics on both servers as required
7. Start both copies of the servers from the command prompt (ex: C:\ ..
\ems\5.1\bin\tibemsd config
C:\ .. \cfgmgmt\ems\data\tibemsd.conf)
8. Test the route by using queue / topic in a BW Process
How to create a transport between RV and EMS?
Transport can be established between RV and EMS topic or queue.
The message can be imported as well as exported from RV.Important point to

remember is, with Topic for transport the messages can be imported and exported
from RV But in the case of Queues the message can only be imported from RV.
Follow these steps to establish transport between RV and EMS :
1)For enabling the transport :
In the configuration file tibemsd.conf set the parameter tibrv_transports to enabled.
The default value is disabled.
2)To set the type of parameters for tranport:
In the transports.conf file set the parmeters in Transport definitions (in the
configuration file transports.conf) specify the communication protocol between EMS
and the external system.
The parameters can be as follows:
[RV01]
type = tibrv
topic_import_dm = TIBEMS_RELIABLE
service = 7200
network =
daemon = tcp:host:7200
topic_import_dm= TIBEMS_NONPERSISTENT
Here
RV01 is the name of the transport.
type = required parameter which can be set to tibrv or rvcm(for certified messages)
service = UDP port.if absnt the default is 7200
network = IP address.
Daemon = TCP Port.
topic_import_dm = delivery mode for importing the messages and the values can
be TIBEMS_RELIABLE,
TIBEMS_PERSISTENT OR TIBEMS_NONPERSISTENT
Similarly the paramters can be set for topic_export_dm and queue_import_dm.
export_headers = The default
value is true and can be set to false if there is no requirement of exporting the JMS
headers.
export_properties = The default value is true and cane be set to false if there is no
requirement of exporting the JMS properties.
3)Destination definitions (in the configuration files topics.conf and queues.conf) can
set the import and export
properties to specify one or more transports.
Can set the import/export properties by either making an entry in topics.conf or

queues.conf filesdirectly like

topic.sample import="RV" where topic.sample is the name of the topic.
or in the admin tool use :
addprop topic myTopics.news import="RV01,RV02" which will add property import
to myTopics in topics.conf files
Key Points:
The transport takes place when the topic name and the RV subject name are same.
For topics:
When a topic specifies import on a connected transport, tibemsd imports messages
only when the topic has registered subscribers.
For queues:
When a queue specifies import on a connected transport, tibemsd immediately
begins importing messages to the queue, even when no receivers exist for the
queue.
When a topic and a queue share the same name, at most one of them may set the
import property.
For example, if a topic example.transport and a queue example.transport are both
defined, only one may specify the import property.
TIBCO EMS Multicast - Features
TIBCO EMS is a distributed and reliable architecture, with support for load-balancing,
routing, and fault tolerant configurations that together remove single points of
failure.
Features
By using TIBCO's messaging solution, companies have been able to reliably support
over 50,000 messages per second and achieve 99.999% uptime.
A distributed message bus with multi-protocol support for Java Message Service
(JMS), TIBCO Rendezvous, and TIBCO SmartSockets. TIBCO supports many of the
leading open standards, including web services, and provides adapters for thirdparty applications and infrastructure including IBM MQSeries. This makes it possible
for companies to reuse their existing investments and focus on delivering new
functionality Built-in monitoring and management capabilities that provide detailed
administrative functions and statistics and support automation through an
administrative API or command-line shell. Companies can also leverage TIBCO's
common monitoring and management framework for top-down, end-to-end
distributed monitoring and management of TIBCO and non-TIBCO products
Multicast Features
Multicast is a messaging model that allows the EMS server to send messages to

multiple consumers simultaneously by broadcasting them over an existing network.

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
subscriber for each of theconsumer 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
Fault-Tolerance setup-A(Which deals with configuration of the files for fault
tolerance)
Note:The Ems data store should be in SAN or NAS,in actual Production
Environment..so that the datastore is accessible by both primary and back up server
SAN-Storage Area Network
NAS-Network Area storage
But for our case we would use just operating system file system (shared by both
primary and Backup server)
Fault Tolerance configuration setup
Parameters will be in Bold and Inclined for easy identification
Configuring Primary server
open the c:\tibco\ems\bin\tibemsd.conf (This file is called Ems configuration file)
Server=EMS-SERVER-RAMU(This value is upto your choice)
Listen=tcp://7222(This value is upto uour choice)
Ft_active=tcp://7444(This value is upto your choice)
Configuring Backup server
Create a folder called Backup in that please copy all the *.conf files(only
configuration files) from c:\tibco\ems\bin\ and place it in c:\tibco\ems\bin\Backup\
Note:From now we will work in the Backup Folder, open tibemsd.conf file in the
folder
Server=EMS-SERVER-RAMU(This value must match the value of the server

parameter in primary server's tibemsd.conf file)

Listen=tcp://7444(This value must match the value in Ft_active paramter in primary
server's tibemsd.conf file)
Ft_active=tcp://7222(This value must match the value in Listen parameter in
primary server's tibemsd.conf file)
store=c:\tibco\ems\bin\datastore(This value must match the value in store
parameter in primary server's tibemsd.conf file,note that the value in primary
server's tibemsd.conf file is just datastore)

Prepend this path to c:\tibco\ems\bin\Backup\ below list in the backup sever

tibemsd.conf
users=c:\tibco\ems\bin\Backup\users.conf
groups=c:\tibco\ems\bin\Backup\groups.conf
topics=c:\tibco\ems\bin\Backup\topics.conf
queues=c:\tibco\ems\bin\Backup\queues.conf
acl_list=c:\tibco\ems\bin\Backup\acl.conf
factories=c:\tibco\ems\bin\Backup\factories.conf
routes=c:\tibco\ems\bin\Backup\routes.conf
bridges=c:\tibco\ems\bin\Backup\bridges.conf
transports=c:\tibco\ems\bin\Backup\transports.conf
tibrvcm=c:\tibco\ems\bin\Backup\queues.conf
durables=c:\tibco\ems\bin\Backup\durables.conf
If you observe the tibemsd.conf file in primary server and compare the tibemsd.conf
file in Backup server
The values for some parameters in primary tibemsd.conf file is jfor example
"users=users.conf" where as in backup server tibemsd.conf file we give
"users=c:\tibco\ems\bin\Backup\users.conf".The reason why because while installing
the Ems server ,it sets these values and it knows where to look for the path , so
thats the reason why the full path is not mentioned for various parameters in
tibemsd.conf for primary server
Fault-Tolerance Setup-B(which deals with starting primary and back up server--which
will be in standby mode)
This post is continuation of Fault Tolerance Setup-A
Go to All programs>Run>type cmd
You will get a command prompt window
Type command: cd c:\tibco\ems\bin
Now you will be inside bin directory
Start Primary Server
Type command: tibemsd (This is a application )

Start Backup Server

Open another command prompt
Navigate to the directory by entering the below command
cd c:\tibco\ems\bin
Give the following command
tibemsd -config Backup\tibemsd.conf (This is not done in primary but you are doing
in back up server , since Primary server tibemsd.conf file is in same directory as
tibemsd application)
In the backup sever command prompt you can see that it is in standby mode for
primary (tcp://7222)
Recently, my ex-teammates had been engaged in a POC (Proof of Concept) test for the biggest
Mobile operator in China . One of the test cases is an exception test. It requirements kill the process
to simulate system crash and then restart the process. At last check if there are any data lost during
the exception test. My teammates met some trouble in this test case; about twenty records of data
lost, the total data count is about several hundred thousand. They sent the BW process to me and
try to find out the reason that cause the data lost. The BW process is like this.

This BusinessWorks (BW) process receive message from a Queue in EMS server, process the
message, then sent the result to another Queue in EMS server. The Acknowledge Mode of the JMS
Queue Receiver is Auto. From this process, it's very easy to find the problem, when the process had
been killed during the process running, the EMS message had been received and acknowledged by
JMS Queue Receiver, but it had not been processed completely, so this message lost. And in this
test, we increase the thread count to 64 (default is 8) to get better performance, this means when the
process had been killed, maybe less than 64 process threads are running, so we might get less than
64 records of data lost (we got about 20).

To resolve this problem, the messages should not be acknowledged on the server before the
process finished running. If the message don't acknowledge, process can re-receive the message
again after it restart. So we modify the BW process like this:

In this BW process, JMS Queue Receiver's Acknowledge Mode is Client, and a Confirm activity had
been added as the last activity of the process. The EMS message will only be acknowledged after
the Confirm executed. If the process crashed, the EMS won't be lost and it can be processed again
after the process restart.

But there is problem in this process, too. There is a JMS Queue Sender in this process. It sends the
processed message to another Queue. If use the above process, JMS Queue Sender maybe invoke
repeated. For example, the process crash after JMS Queue Sender and before Confirm, the
message won't be acknowledge in the server, when the process restart, this message will be
reprocessed. So in the test record, maybe some repeated records will be found. The BW process
should be modified more.

In this process, Confirm is added before JMS Queue Sender and a CheckPoint is added between
Confirm and JMS Queue Sender. A checkpoint saves the current process data and state so that it

can be recovered at a later time in the event of a failure. If a process engine fails, all process
instances can be recovered and resume execution at the location of their last checkpoint in the
process definition. If a process instance fails due to an unhandled exception or manual termination, it
can optionally be recovered at a later time, if the process engine is configured to save checkpoint
data for failed processes. So let's check this process, if the process crash before Confirm, then it will
reprocess the message after restart. If it crash after Checkpoint, then when the BW process archive
restart, the process will continue execute from Checkpoint. Those can ensure the transaction
integrality. But this process is not prefect too. If the process crash between Confirm and Checkpoint,
then the data will lost. But the probability is tiny, because the Elapsed Time of Confirm is very shorter
than JMS Queue Sender, it can't take many time to execute, so the probability of the process crash
at confirm is very low. Maybe lost one or two records in one million records; it's an acceptable result
in the POC. And the performance of this process is very good.

If the scenario is the customers' product environment, it requires no data lost. How to configure the
process? Use Transaction is a good idea. BW process is like this:

Add the Confirm and JMS Queue Sender into a Transaction. Only the two activities all success, the
process will be finished. So wherever the process crash, the data won't lost or duplicate. But the
performance will a little lower when use the Transaction. We can use it according the customers'
actual product environment.

1. What are the two storage methods used by Tibco EMS server?
Ans : File based and database
2. What files are created in file based data storage method?
Ans . sync.db,async.db,meta.db
3. What information does Meta.db contain?
Ans . Durable subscribers, fault tolerant connections and other Meta data.
4. What does flow control property specifies?
ans . Specifies the maximum size of the pending messages in server.
5. What are the destinations of messages?
Ans : topics and queues.
6. in how many ways destinations for messages can be created?
Ans . static : administrator creates destinations and client programs uses the
destinations
Dynamic: here client program creates destinations during runtime
Temporary: servers connected through routes communicate through temporary
destinations.
7. what are the messaging models supported by ems serve?
Ans . point to point ( queues), pubsub (topics), multicast (topic).
8.What is the diff between exclusive queues and non exclusives ?
Ans . in exclusive only one receiver can take message where as in non exclusive
many receivers can receive msg.
9.how long the message will be stored for durable subscribers?
Ans . as long as durable subscriber exists or until msg expiration time reached or
storage limit has been reached.
10. what are the different delivery modes supported by ems?
Ans . persistent, non persistent and reliable.
11.what is the dis advantage of reliable mode delivery?
Ans . in reliable , with out knowing the status of the consumer the publisher keeps
sending msg to server
12. what is the condition for persistent message to be stored on disk in topics?
Ans . there must be atleast one durable subscriber or one must be connected to
fault tolerant connection to ems server.
13. how do you distinguish dynamic queues and static queues.?
Ans . dynamic queues have * before the queue name.
14. what happens if npsend_checkmode parameter in tibemsd.conf file is enabled?
Ans. Server sends acknowledgement for non persistent message.
15. what is shared state in fault tolerant operation ?
Ans . primary server and backup server have connection to shared state which
contain information about client connection and persistant messages.
16. how many ways a back up server detects failure of primary server?
Ans. Hearbeat failure:-Primary server sends a heartbeat message to backup server
to indicate primary server is working .

connection failure :-backup server detects the failure of tcp connection with
primary server
17.what is the use of locking in fault tolerant operation?
Ans.Inorder to prevent the backup server to take the role of primary server, the
primary server locks the shared state in normal operation and during the failure of
primary server backup server takes the lock and access primary server.
18.If authorization is enabled in tibemsd.config file what is the condition to
configure ems server as fault tolerance?
Ans.Server name and password for both primary and backup server should be same
and username and password for both servers should match the server and
password parameters in tibemsd.config file.
19. what are the changes to be made in config file for ems fault tolerant operation?
Ans . in primary server give url of backup server to ft_active parameter and in
backup server give url of primary server for ft_active parameter.
20. different types of zones?
Ans. Multihop zone and 1hop zone.
21. what is fail safe?
Ans. In fail safe mode messages are first stored in disk before sending messages so
that no messages are lost.
22.what is the default port number for ems server?
Ans 7222.
23. Difference between rendezvous and ems?
Ans. Rvd is bus based architecture, ems is centralized architecture
24.what are different acknowledge modes?
Ans. Dups_ok_acknowlwdge, auto_acknowlwdge, client acknowledge, no
acknowledge.
25. How many ways we can determine the life span of the message in
a queue. What are they?
Ans: expiration parameter in queue configuration file.
JMS expiration time in queue sender.
The JMS expiration time in queue sender overrides any value given in config.
26. What are the message storing mechanisms of queues?
Ans: persistent and non-persistent.
Persistent: messages are stored to external storage before sending.
Non-persistent: not stored to any external storage. The information will not be
available for retrieval.
27.what is condition to create bridge?
Ans. Queus and topics must be defined as global.
28. why do we need routers ?
Ans. To transfer messages between different ems servers.
29. what is the default maximum size of message?
Ans. 512mb
30. how do you configure client for fault tolerant connection?
Ans. Specify multiple server as a comma-separated list of URLs and both URLs must

use same protocol either tcp or ssl.

Q: what is message sequencing in queues?
When the message size is large, and when there are more messages with larger
size, to reduce the load on the server, the sender sends the message in chunks and
on receiver side to receive the messages in order, use message sequencing.
Q: what is the difference between load balancing and fault tolerant modes?
Load balancing is done between 2 or more servers where the load is distributed
between servers. Whereas, fault tolerance is done between 2 servers where one
server acts as a primary and the second server acts as a backup server for the
primary server. In case of failure of primary server, the second server (backup
server) becomes the primary server.
Q: what is load balancing in queues?
There will be number of queue receivers and the messages are sent to the
queues in round robin fashion thereby reducing the load.
Q: what is the use of durable topic?
In durable topic, the message is first persisted on to the disk before it is
published. Durable topics ensure the delivery of messages like queues. Whereas
a regular topic receives the message only when it is active. If not active the
message is lost.
Q: what are the services of ems server?
Reliable, guaranteed, Transactional
Q: how do u do performance tuning?
Performance tuning can be done at EMS server level/Administrator level
In EMS it can be done by using prefetching mechanism, there by regulating the
consumption of messages. The prefetching mechanism is available in both
queues and topics
In Administrator, performance tuning is done by adjusting the count of the
threads. Also by setting the flow limit, activation limit, max limit.
Q: why load balancing is not helpful with topics?
Because as one message is sent to all the subscribers that subscribe to the
topic, there will be duplication of messages and there will be more
disadvantages when used in topics.
Q: what are the different acknowledgement modes and difference between
them?
auto, client, dups_ok, explicit client ack, no acknowledgment,
explicit_client_dups_ok ack,transitional, local transitional. Go through the articles
in the site. I believe there is explaination for these.

Q: Have you worked on EMS? What are pros and cons of using EMS server over
Rendezvo
Ems follows server centric architecture
rv follows bus architecture in
secured and reliable delivery of data in ems
no reliability rv compare that of ems
there is 2 ack in ems but in ems not there
1. 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
3. 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.
4. What is the purpose for stores.conf
a. This file defines the locations either store files or a database, where the EMS
server will store messages or metadata.
b. Each store configured is either a file-based or a database store.
5. How many modes are the messages written to store file.

2 modes.. sync or async. When absent , the default is async

6. What is tibemsd.conf
It is the main configuration file that controls the characteristics of the EMS server
7. How many delivery modes for messages?
Persistent, Non-persistent, Reliable-delivery.
8. What is the maximum messagesize?
Ems supports max message size of 512 mb
9. Name 3 destination properties and explain them.
Global, secure, maxmsgs, maxbytes, flowcontrol, sender_name,
sender_name_enforced, trace,maxRedelivery
10.

What are the different modes of installation in Ems?

a. GUI mode
b. Console mode
c. Silent mode
11. What are the messaging models supported by JMS
a. Point-to-point
b. Publish-subscribe
c. Multicast
12. Tell me about routes
What is the purpose of routes, what kind of destinations can be used in routes?
Topics and queues m-hops
13. 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.
14. In how many ways can a destination be created?
a. Static-created by user

b. Dynamic-created by ems server on the fly.

c. Temporary destinations.
15. What are the wild cards that we use in ems?how do they work for queues and
topics
*,>
U can subscribe to wildcard topics but cant publish to them. Where as in case of
queues we cant either send /receive.
16. Are bridges transitive?
NO
17. Tell me about flow control on destinations
Sometimes the publisher 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.
18. Tell me about flow control on bridges and routers
Flow control has to be specified on both sides of bridges whereas on routes it
operates differently on sender side and receiver side.
19. Name 3 configuration files and tell me what it consists of
a.
b.
c.
d.
e.
f.

Queues.conf
Topics.conf
Routes.conf
Factories.conf
Stores.conf
Groups.conf,users.conf,transports.conf

20. Name some administrative level destination properties

a.
b.
c.
d.
e.

View
Create
Delete
Modify
Purge

21. How can you change the configuration properties of EMS server
You can change in the tibemsd.conf file or you can change using the ems admin
console.

22. What are the permissions that you can grant to users to access queues
a. Receive
b. Send
c. Browse
23. What are the permissions that you can grant to users to access topics
a.
b.
c.
d.

Subscribe
Publish
Durable
Use_durable

24. Tell me about multicasting in EMS

a. 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.
b. Each multicast enabled topic is associated with a channel.
25. What are the advantages and disadvantages of multicasting?
a. Advantages: as the message broadcasts only once thereby reducing the amount
of bandwidth used in publish and subscribe model. Reduces the network traffic.
b. Disadvantages: Offers only last-hop delivery. So cant be used to send messages
between servers.
26. On what destinations can you use multicast?
a. Topics
27. Suppose, you got an error while accessing a queue, that you dont have
necessary permissions to access the queue. What might be the solution/reason?
a. The user that is assigned to the queue and the user used while creating
28. How does the secondary server know that the primary server is failed?
a. Based on heartbeat intervals
29. What is JMS queue requestor?

a. 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
30. What is JMS topic requestor?
a. The JMS Topic Requestor activity is used to communicate with a JMS
applications 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.
31. How do you add ems server to administrator?
a. Using domain utility
32. How do you remove individual messages from destinations?
a. Using purge command.
What are the different acknowledgement modes available in TIBCO EMS?
1)Auto
2)Client
3)TIBCO EMS Explicit Client Acknowledge
4) Dups OK
5)Transactional
-> In Auto acknowledgement and Dups-OK acknowledgement modes, the
message is acknowledged automatically when it is received. The only
difference between Auto acknowledgement and Dups-OK is that the later
mode is for lazy acknowledgement purpose.
-> In Client and TIBCO EMS Explicit Client Acknowledge modes, the
message will be acknowledged at a later point by using the Confirm
activity. A process definition must confirm the message when using this
acknowledge mode.
The difference is that in Client acknowledge mode, if the message is not
confirmed before the process instance ends, the message is redelivered
and a new process instance is created to handle the new incoming
message, where as, in TIBCO EMS Explicit Client Acknowledge mode, The
session is not blocked and one session handles all incoming messages for
each process instance. If a message is not confirmed before the process
instance ends, all messages received in the same session are redelivered

-> Transactional mode is used when a transaction that can process JMS
messages is included in the process definition. The message is
acknowledged when the transaction commits.
Secured queue & secured topic.
Secured queue means controlled messages sending and receiving activity.
Foe example if I want to create queue which will send to message to fix destination
or receive message form fix queue. E.g. is test1 queue
Using administration tool you can create secured queus for example.
Start ems administration tools login with administrative rights.
Set server authorization= enabled
Create queue test1 secure
Grant queue test1 rahil send
Grant queue test1 akash send
Grant queue test1 kajal receive
So now dilip and akash user can send message and kajal will receive and kajal can
not send and dilip and akash can not receive message from queue test1.
Same way we can secure topic also.
What is sequencing in queue receiver?
It is way of receiving/processing message based on priority, gropu or userid.
Sequencing is done with the help of x path formula.
Use of Bridges and routes?
They are used from channeling message from senders to receiver. Bridge act as
connector between two different queue and Routes act as connector between
different server for sending message and receiving acknowledgement of delivery.
Exclusive queue
The queue can be configured exclusive then all queue messages are retrieved
by the first consumer specified for the queue. It is useful when we want only one
application to receive messages from specific queue. Non exclusive queues are
useful in case of load balancing the load of incoming messages from different
receiver.

Q
What are steps to follow to deploy a project in the Tibco Admin or
any other build scripts

How will configure the Fault tolerant and Load Balancing in Admin

20. What is the difference between queues and topics?

Ans: Queues and Topics

transportation in EMS.

both

are

used

in

message

store

and

Queues are used in point to point communication mode where as Topics

are used in Publish Subscribe communications.
Queues can assure the message deliver even if the reader/receiver is not
active.
Topics case messages cannot be sent if consumer is not active. but we can
assurance by making them as durable

Queues are more secure than Topics

21. What is the use of bridges in ems?

Ans: Using bridge concept in EMS we can send messages between

applications to applications without changing the application code. We can
simply using the same application logic with defined topics and queues.
Here we simply bridge the desired topics to queues or queue to queue or
topic to topic vice versa.
If u wants to send message between different messaging destinations
within the EMS serve then go for bridge and its unidirectional
32. What are the properties that we can set to a queue or topic?

Ans: Secure, failsafe, global, prefetch, maxmsgs, maxbytes, export,

import, flowcontrol, sender_name, trace, expiration, overflowpolicy, store
and channel

33. What are the protocols that RV and EMS use?

Ans: EMS uses TCP protocol where as RV uses TRDP over UDP which will
provide TRDP for secure communication.

34. What is fault tolerance and Load Balancing in tibco EMS and where to
configure?

Ans: Fault Tolerance: The arrangement of failover recovery in EMS to

assist client communications to EMS is called Fault Tolerance. Setting up
primary and secondary EMS servers in an environment.
Load Balance:

35. What are the configuration files present in EMS/?.

Ans: tibemsd.conf EMS server config file which reads other config files
queues.conf, topics.conf, durables.conf, acl.conf, user.conf, group.conf,
bridges.conf, route.conf etc.
40. What are the acknowledgement modes available in tibco EMS?

Ans: These are the following acknowledgement modes in EMS and JMS

JMS: The JMS specification defines three levels of acknowledgement for

non-transacted
Sessions.
a). Auto
b) Client Acknowledgement.
c) Dups-Ok Acknowledgement.

EMS: EMS extends the JMS acknowledge modes to include:

a) NO_ACKNOWLEDGE
b) EXPLICIT_CLIENT_ACKNOWLEDGE
c) EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE

45. What is the use of durable subscribers?

Ans: Durable subscribers are those who can subscribe messages at later
point of time whenever they are active.

48. How to define security to EMS sever Or use of SSL in tibco EMS?

By using this SSL we can provide security to the EMS messages for this
will have configure the SSL certification file,
46. What is file based storage and database storage in TIBCO EMS and
where we will configure it?

Ans: In file based store all messages will be saved on disk. Where as in
database storage all messages will write on db. If we check in stores.conf
we can find file storage and database storage. By default any message will
be stored in the file.

Note: In EMS 6.0 there is no concept of server or data base storage. By

default all the messages gets stored on the disc itself.

57. What is the difference between Get JMS queue and Wait for JMS queue
message activity?

The Get JMS Queue Message activity retrieves a message from the
specified queue. This activity allows you to perform a receive operation on
the queue as opposed to waiting for a queue message to be delivered to
the Wait for JMS Queue Message activity or the JMS Queue Receiver
process starter.
The Wait for JMS Queue Message activity uses event key which is the
JMSCorrelationID to filter the right response with the right job. The key
is the JMSMessageID sent by the Queue Sender activity
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 servers databases
syntax : show db [sync|async]
example: show db
Soap over JMS:
create factory QueueConnectionFactory queue URL=tcp://7222
create factory TopicConnectionFactory topic URL=tcp://7222

There is a sample SSL configuration you should start with in

<tibco_home>/ems/<version>/samples/config called tibemsdssl.conf.
Start it with tibemsd -config tibemsdssl.conf.
Take a look at the properties.
The EMS Server is using the certificate server.cert.pem as its identity, adn it will trust
certificates that were signed by
client_root.cert.pem.
ssl_server_identity = ../certs/server.cert.pem
ssl_server_key = ../certs/server.key.pem
ssl_password = $man$WjtSRCpaXu7hoTkDlcEPr6KNKRr
# Server Issuer certificate(s).# Supports PEM, DER and PKCS#12.# This may be a part of
PKCS12 specified by

ssl_server_identity
ssl_server_issuer =
# Trusted issuers of client certificates. Supports PEM, DER and PKCS7.
ssl_server_trusted = ../certs/client_root.cert.pem
Soyou can use client_identity.p12 in your BW project as an Identity (there is a
README in the certs directory explaining the relationships), and
use server_root.cert.pem so you can trust theserver.cert.pem by importing it into a
Trusted Certificates folder in your BW project.
There are also SSL properties for FT heartbeats:
ft_ssl_identity =
ft_ssl_issuer =
ft_ssl_private_key =
ft_ssl_password =
ft_ssl_trusted =
ft_ssl_verify_host =
ft_ssl_verify_hostname =
ft_ssl_expected_hostname=
ft_ssl_ciphers =
If you are using Tibco EMS, you should be aware that there is a decent tool that comes with
the Tibco SDK that allows you to monitor all activity that goes on in your broker. In the
directory c:\tibco\ems\bin, you will find a command-line application
called tibemsmonitor.exe. If you run this utility, you can see every connect/disconnect,
every creation and destruction of a MessageProducer and MessageConsumer, every
creation of a topic or queue.
tibemsmonitor -monitor <topic>
[-server <server-url>]
[-user <name>]
[-password <password>]
[-selector <text>]

[-short]
[-help]
[-helpssl]
tibemsmonitor -server tcp://emshost:7222 -monitor >
tibemsadmin [-server] [-user] [-password]
tibemsadmin.exe -server tcp://emshost:7222 -user admin -password admin123
tibemsd
[-config <filename>]
[-ft_active <active_url>]
[-ft_heartbeat <seconds>]
[-ft_activation <seconds>]
[-ssl_password <string>]
[-trace <items>]
[-ssl_trace]
[-ssl_debug_trace]
[-help]
tibemsd -config c:\tibco\cfgmgmt\ems\data\tibemsd.conf

How to Secure the Database Password in EMS 5.x

Configuration file?
OCTOBER 31, 2010LEAVE A COMMENT

Rate This

When defining the database stores in EMS 5.x, you will need to define the following
parameters instores.conf:

dbstore_driver_url = JDBCURL
dbstore_driver_username = username
dbstore_driver_password = password
The database password can be entered as clear text for two parameters:
dbstore_driver_password and dbstore_driver_url.
1. dbstore_driver_password
You can also use a mangled password for the dbstore_driver_password. That is, you can
use the tibemsadmin tool to mangle a database password and define the mangled
password for dbstore_driver_password.
For example, you can run the tibemsadmin command to mangle a clear text password:
===================================================
tibemsadmin.exe -mangle
TIBCO Enterprise Message Service Administration Tool.
Copyright 2003-2008 by TIBCO Software Inc.
All rights reserved.
Version 5.0.0 V27 4/29/2008
Enter phrase to mangle:
Confirm phrase to mangle:
$man$-RV84410jfkIKs3GET2dmcc5MPs
===================================================
In stores.conf, you can define the mangled password for dbstore_driver_password:
dbstore_driver_password=$man$-RV84410jfkIKs3GET2dmcc5MPs

2. dbstore_driver_url
When defining dbstore_driver_url for an Oracle database, the URL format is entered as
following:
jdbc:oracle:thin:/@:/{remote database name} If you dont want to enter the clear text
database password within the URL, you can define the Oracle service name (aliase name)
for the database using the following syntax: dbstore_driver_url=jdbc:oracle:thin:@:/
{dbservice name}
This way you dont need to define dbusername and dbpassword in the dbstore_driver_url
parameter.

Messaging
What are the Messaging Tools Provided by TIBCO?
EMS
Rendezvous
What is the difference between EMS & RVD?

EMS
Uses TCP
Functions within the IP Layer
Can be used within the Intranet and the Internet
Slower than RVD
RVD
Uses UDP
Functions within the Network Layer
Considerably Faster than EMS
Can be used only within the Intranet (LAN)
What are the Messaging Modes?
P2P (Queue)
Pub / Sub (Topic)
What are the two types of Delivery Modes in Messaging?
Synchronized
Asynchronized
What are the Services provided by Messaging?
Reliable (At Least Once)
Guaranteed (At Most Once)
Transactional (Only Once)
What are files used by TIBCO to maintain the Connection details?
Meta.db (Connection Details)

Async.db (Fire & Forget Messages)

Sync.db (Acknowledge Back Messages)
What are the configuration files used by TIBCO EMS?
Tibemsd.conf
Queue.conf
Topic.conf
What is the maximum size and maximum number of message possible using TIBCO EMS?
Maximum Message Size = 512MB [ Both Topic & Queue ]
Maximum No. Of Messages = 3600 messages / second
What is the Maximum Retransmission Time?
Maximum Retransmission Time = 60 seconds
What are the delivery modes supported by EMS server?
Persistent
Non-persistent
Reliable
What are the message types supported by EMS?
Text
XML
Bytes
Stream
Simple

 Object
ObjectRef
Map

What are the different types of Queues?

Static Queue
Dynamic Queue
Temp Queue
System Queue
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
How do you remove individual messages from destinations?
Using purge command, you can delete messages from queues and topics.
What is the use of Durable option?

Durable option enables persistence for EMS messages by creating Local Inboxes at the receiver end. The
Message will exist as a reference till it is consumed by the corresponding receivers.
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 applications 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.
What is the difference between Queues and Topics?
Queue
Guaranteed Service
Only the Target gets the message (One message per Consumer)
Uses Peer-to-Peer Mode to deliver messages
Blocking
Load Balancing is possible
Topic
Reliable Service
Everyone active gets the message (One message may Consumers)
Uses Pub / Sub mode to deliver messages
Non-Blocking
Load Balancing is not Possible
What is the use of secured queues and topics?

Setting secure property to queues/topics can restrict unauthorized users from publishing/sending and
subscribing/receiving the messages.
What is Load Balancing?
Load Balancing is a technique to distribute workload evenly across two or more machines or resources, in
order to get optimal resource utilization, maximize throughput, minimize response time, and avoid overload.
Using multiple Receivers with load balancing, instead of a single Receiver, may increase reliability through
redundancy.
How is Load Balancing implemented on both Queue & Topic?
Topic : Load Balancing is only possible on Queues
Queue : Load Balancing is implemented on the receivers end. Since Load Balancing not possible on the
sender side.

What is Certified Messaging?

Rendezvous (RV) uses 'UDP'. Therefore each message is sent as a packet with a sequence
number and a subject attached. So, RV is also called as "Subject Based Messaging". Rendezvous
Daemon (RVD) converts the message into packets and publish to the network. At the receiver end,
RVD again converts the packets to the message and sends it to the receiver. This message is
stored only for 60 seconds in the RVD before the message is lost. To avoid this, RV introduced a
concept called
'Certified Messaging(CM)'. RVCM uses Ledger to save the messages. The sender stores all
outbound messages of the registered receivers which have an agreement in the ledger unless the
sender receives an acknowledgement from the receiver.
What is the difference between RVD and RVRD?
RVD is Used for local subnet communication.
RVRD is Used for Remote communication.
What are the steps to perform Server Side Load Balancing on the local machine?
1. Make a duplicate copy of the cfgmgmt Folder and rename it to cfgmgmt2
2. Make sure that the Server Name is same in the tibemsd.conf file in both the folders.

3. Change the port number in the second folders tibemsd.conf file (listen = tcp://xxxx)
4. Start both copies of the servers from the command prompt (ex: C:\ .. \ems\5.1\bin\tibemsd
config C:\ .. \cfgmgmt\ems\data\tibemsd.conf)
5. In TIBCO Designer, modify the JMS Connection Provide URL to contain both the servers
( ex: tcp://localhost:7222 | tcp://localhost:7223)
What is Fault Tolerance?
Fault Tolerance is the ability of a system to respond gracefully to an unexpected hardware or
software failure. Fault Tolerant systems mirror all operations, i.e. every operation is performed on
two or more duplicate systems, so if one fails the other can take over.
What are the steps to setup Fault Tolerance servers on the local machine?
1. Make a duplicate copy of the cfgmgmt Folder and rename it to cfgmgmt2
2. Make sure that the Server Names and Listen ports are not the same in the tibemsd.conf
file in both the folders.
3. Change the port number in the tibemsd.conf file (i.e ft_active = listen port of the other
server) in both the cfgmgmt folders.
4. Start both copies of the servers from the command prompt (ex: C:\ .. \ems\5.1\bin\tibemsd
config C:\ .. \cfgmgmt\ems\data\tibemsd.conf)
What is the use of Bridges?
Some applications require the same message to be sent to more than one destination possibly of
different types. So we use bridges.
What is the syntax to create Bridges without Message Selector?
create bridge source=queue:bridgequeue target=topic:bridgetopic
What is the syntax to delete a bridge?
delete bridge source=queue:bridgequeue target=topic:bridgetopic
What is the syntax to create Bridges with Message Selector?

create bridge source=queue:bridgequeue target=topic:bridge topic selector="keyword"

What
is
the
use
of
Bridges
and
Routes?
Both are used to channel messages from senders to receivers. Bridge act as connector between
two different queue and Routes act as connector between different server for sending message and
receiving acknowledgement of delivery.
What are the steps required to create a Route between two Servers?
1. Make a duplicate copy of the cfgmgmt Folder and rename it to cfgmgmt2
2. Make sure that the Server Name is NOT the same in the tibemsd.conf file in both the folders.
3. Change the port number in the second folders tibemsd.conf file (listen = tcp://xxxx)
4. Set the routing property to enabled in the tibemsd.conf files in both the folders
5. open factories.conf under cfgmgmt2 and change the settings for GeneralConnectionFactory,
QueueConnectionFactory and TopicConnectionFactory URL to (tcp://xxxx)
6. Create Route on Server 1 (route Server2-Name url=tcp://localhost:xxxx)
7. Create global queue / topics on both servers as required
8. Start both copies of the servers from the command prompt (ex: C:\ .. \ems\5.1\bin\tibemsd
config C:\ .. \cfgmgmt\ems\data\tibemsd.conf)
9. Test the route by using queue / topic in a BW Process
EMS

1. What are the destinations in EMS/JMS and their differences?

Ans:
Queues: point-point communication.
Any number of producers and consumers can exist.
Exclusive: only the first consumer who picks up the first message can take the rest of the
messages (used if u want only one consumer).
Non-exclusive: where any number of consumers can exist.used for load balancing.
At any time and situation each message is taken by only one consumer.

Topics: publish-subscribe.
Any number of publishers and subscribers can exist.
Each message can be taken by any number of consumers (radio).

2. What are the different levels of load balancing in EMS and how would you do it?
Ans: server level and consumer level
Server: by having multiple servers.
Consumer: by creating consumer instances.

3. How would you do fault-tolerance in EMS?. Explain the complete process.

Ans: FT in EMS can be achieved by implementing pair of servers called primary and
backup while the primary does the normal job of sending and receiving messages the back
up server takes the place of primary if the primary fails.

The pair shares the information from the shared state. When the primary goes down the
backup server reads all the primary config files and starts from there.

The primary locks the shared state if its active so that the backup server doesnt take its
place. the lock is released when the primary goes down so that the backup can lock the
shared state.

Only persistent messages can be implemented in this situation since non-persistent

messages cannot be stored in external storage like shared state.

4. How a consumer can connect to the new primary EMS server when the running
primary server goes down?
Ans: we can specify multiple URLS for the client so that if the primary is down the next
URL belonging to back up will be used.

In case of a primary having multiple address we can use multiple URLS for the same
server so that even the primary in one location is down it can connect to the primary of
another location.

The URLS are usually comma separated in client config.

5. How the clients of the primary server access the messages stored by primary server
when it goes down and secondary server becomes primary server?
Ans:
clients can be config to be intimated of the failover.

The backup reads the current state of the client from the shared storage
And then connects to the client if there are any undelivered persistent messages.

6. How to setup load balancing for Topics and queues.

Ans:
We can achieve load balancing using bridging queues and topics.
Or
Queues can be set non-exclusive so that any number of consumers can access the queue.

7. Scenario: Topic T1, Queue Q1 and Queue Q3 are bridged. A publisher published a
message to Topic T1. But the publisher has no access rights to Q1. How the message
will be traversed?
Ans: 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.

8. Scenario: A publisher is publishing messages quickly than the consumers are

consuming the messages. How to control this situation.
Ans: we can use flow control to address this situation.
The target maximum size for pending messages is specified so that only that amount of
message is stored and any messages above that will be blocked.

The server blocks the send call and releases only when the storage limit is below the set
value.

The flow control is enabled only if the topic or queue has receivers.

This way the producers are slowed down. And the balance is achieved.

9. Can we set a limit for the total number of pending messages on Queue or Topic? What
is the parameter for that
Ans: yes, max-bytes for pending messages.

10. What if max-bytes limit exceeds?

Ans: Messages that would exceed the limit will not be accepted into storage and an error is
returned to the message producer.

11. How flow control property functions?

12. What is the pre-fetch value?
Ans: in order for reducing the clients waiting time in a server client scenario
For a queue based messaging only the prefetch value allows the the server to send
messages in batches so that the message will be ready for the client when ever the client
is ready. For automatic fetching its >1 and for disabling its none.

13. What are different kinds of acknowledgement modes?

Ans: DUPS_OK_ACKNOWLEDGE, for consumers that are tolerant of duplicate messages.
AUTO_ACKNOWLEDGE, in which the session automatically acknowledges a clients
receipt of a message.
CLIENT_ACKNOWLEDGE, in which the client acknowledges the message by calling the
messages acknowledge method.
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.

14. How many types of queues we can have in a server?

Ans: exclusive and non-exclusive.
Exclusive queues : only one consumer can take messages from here.
Non-exclusive: any number of consumers can take messages. Used for load balancing.

15. How do we distinguish dynamic queues with static queues?

Ans: dynamic queues have * before them.

16. What are the message storing mechanisms of queues?

Ans: persistent and non-persistent.
Persistent: messages are stored to external storage before sending.
Non-persistent: not stored to any external storage. The information will not be available for
retrieval.

17. What are types of subscribers we can have for topics? Explain them in detail.
Ans: durable and non-durable subscribers.
In durable subscriptions the messages are stored so that even if the subscriber fails and
comes back the messages can be retrieved.

18. What is fail-safe?

Ans: the Tibco ems provides 2 modes for persistent topic/queue message storing to
external device.
Normal: in this mode the messages stay in a buffer before writing to a storage(disk). So in
case of any failure the messages may be lost.
This mode is very efficient in situations were little loss of data is allowed.

Failsafe: in the fail safe mode the messages are first written to an external storage before
sending so that no messages are lost ever. This is used when no loss of data can be
encouraged.

19. How many ways we can determine the life span of the message in a queue. What are
they?
Ans: expiration parameter in queue configuration file.
JMS expiration time in queue sender.
The JMS expiration time in queue sender overrides any value given in config.

20. What are the basic configuration you would setup if you want to enable your EMS
server for SSL communication
Ans: listen parameter and ssl_server_identity. Optionally private key.

21. what is the structure of messages in JMS?

Ans: header(needed),properties(optional),body(optional).
Header parameters: JMS destination, JMS message mode,

21. What is the main config file in JMS?

Ans: The main configuration file controls the characteristics of the TIBCO Enterprise
Message Service server. This file is usually named tibemsd.conf, but you can specify
another file name when starting the server.
Exp para: server, password,flowcontrol,storage,server sartup