Académique Documents
Professionnel Documents
Culture Documents
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.
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
queues
and
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.
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.
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
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
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
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
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.
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
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
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
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.
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
Queues.conf
Topics.conf
Routes.conf
Factories.conf
Stores.conf
Groups.conf,users.conf,transports.conf
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
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
both
are
used
in
message
store
and
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: 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
a) NO_ACKNOWLEDGE
b) EXPLICIT_CLIENT_ACKNOWLEDGE
c) EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE
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.
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
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
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
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
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)
Object
ObjectRef
Map
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.