TIBCO EMS

Author: Hanmanth Reddy Koppela (EMP# 1109740)

Disclaimer:
I hereby declare that this document is based on my personal experience(s) in my
project. To the best of my knowledge, this document does not contain any material
that infringes the copyrights of any other individual or organization including the
customers of CSC.

TIBCOs Enterprise Messaging Offering

Message MODELS

JMS Message Models

Point-to-Point (Queues)

Publish Subscribe (Topics)

Multicast (Topics)

Point-to-Point(Queues)

TIBCO EMS Server

Message
Producer

Queue
Send Message

Receive Message

Acknowledge

Message
Consumers

Publish-Subscribe(Topics)

TIBCO EMS Server

Subscribe to Topic

Message
Producer

Topic
Publish Message

Deliver Message

Acknowledge

Message
Consumers

Multicast(Topics)
Multicast Daemon

TIBCO EMS Server

Message
Producer

Multicast
Topic

Broadcast Message

tibemsmcd

Publish Message
Deliver Message

Subscribe to Message

Message
Consumer

EMS : An extension to JMS

EMS Extensions to JMS Messages - I

JMS provides 2 delivery modes for messages

PERSISTENT

NON_PERSISTENT

EMS adds the 3rd delivery mode

RELIABLE_DELIVERY

EMS Extensions to JMS Messages - II

For restriction of acknowledge messages in JMS

NO_ACKNOWLEDGE mode

To restrict acknowledgement in EMS, there are

also

EXPLICIT_CLIENT_ACKNOWLEDGE mode
EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE mode

EMS Extensions to JMS Messages - III

EMS extends MapMessage and StreamMessage

body types of JMS which allow EMS to
exchange messages with TIBCO RV and
ActiveEnterprise formats.

The extensions are :

Can nest a MapMessage or StreamMessage

Can use arrays as well as primitive types for
values

Message STRUCTURE

Message Structure
REQUIRED

HEADER
PROPERTIES
BODY

Message Headers
JMSDestination

Destination to which message is sent.

JMSDeliveryMode

Persistent, Non-persistent or Reliable.

Default is Persistent.

JMSExpiration

Length of time the message will live before expiry.

If the server expiration property is set for a destination, it will

override the JMSExpiration value set by the message producer.

Message Headers

JMSPriority

JMSMessageID

Priority of the message. Larger numbers indicate higher

priority.

Unique identifier for a message.

JMSTimeStamp

Timestamp of the time when the message was handed off

to a provider to send. Message may actually be sent later
than this timestamp.

Message Headers

JMSCorrelationID

JMSReplyTo

This ID can be used to link messages, such as linking a

response message to a request message.

A destination to which a message reply should be sent.

JMSRedelivered

If this field is set, it is possible that the message has been

delivered to the client earlier, but not acknowledged at
that time.

Message Properties

JMS_TIBCO_CM_PUBLISHER
JMS_TIBCO_CM_SEQUENCE

JMS_TIBCO_COMPRESS
JMS_TIBCO_DISABLE_SENDER
JMS_TIBCO_IMPORTED

JMS_TIBCO_MSG_TRACE
JMS_TIBCO_MSG_EXT
JMS_TIBCO_SENDER
JMS_TIBCO_SS_SENDER

JMS_TIBCO_PRESERVE_UNDELIVERED

Undelivered Message Queue

HEADER
HEADER

Message Expiry

OR

1
PROPERTIES
PROPERTIES
SERVER
SERVER
BODY
BODY

JMS_TIBCO_PRESERVE_UNDELIVERED
= TRUE
Undelivered message
queue
JMS_TIBCO_PRESERVE_UNDELIVERED
=
FALSE
$sys.undelivered
$sys.undelivered

2
Queue
maxRedelivery

Message Body
MESSAGE TYPE

CONTENTS OF BODY MESSAGE

Message

No Body

Text Message

Java.lang.String

Map Message

Name/Value pairs

Bytes Message

Stream of bytes

Stream Message

Stream of primitive data types

Object Message

Serializable object

EMS supports messages up to a maximum size of 512MB

Message DELIVERY MODES

Persistent

When a producer sends a PERSISTENT message,

the
producer must wait for the server to reply
with a
confirmation.

The message is persisted on disk by the server. This delivery

mode ensures delivery of messages to the destination on the
server in almost all circumstances.

However, the cost is that this delivery mode incurs two-way

network traffic for each message or committed transaction
of a group of messages.

Persistent
Message

Message
Producer

EMS Server

Acknowledgement

Non Persistent

Sending a NON_PERSISTENT message omits the overhead of

persisting the message on disk to improve performance.

If authorization is disabled on the server, the server does not

send a confirmation to the message producer.

If authorization is enabled on the server, the default

condition is for the producer to wait for the server to reply
with a confirmation in the same manner as when using
PERSISTENT mode.

Non Persistent
Regardless of whether authorization is enabled or disabled, you
can use the npsend_check_mode parameter in the
tibemsd.conf file to specify the conditions under which the
server is to send confirmation of NON_PERSISTENT messages to
the producer.
Message

Message
Producer

EMS Server

Depending on
npsend_check_mode

Reliable Delivery

EMS extends the JMS delivery modes to include reliable

delivery. Sending a RELIABLE_DELIVERY message omits the
server confirmation to improve performance regardless of
the authorization setting.

Message
Producer

Message

EMS Server

Reliable Delivery

When using RELIABLE_DELIVERY mode, the server never sends

the producer a receipt confirmation or access denial and the
producer does not wait for it.

Reliable mode decreases the volume of message traffic,

allowing higher message rates, which is useful for messages
containing time-dependent data, such as stock price quotations.

When you use the reliable delivery mode, the client application
does not receive any response from the server. Therefore, all
publish calls will always succeed (not throw an exception)
unless the connection to the server has been terminated.

Reliable Delivery

In some cases a message published in reliable mode may be

disqualified and not handled by the server because the
destination is not valid or access has been denied.

In this case, the message is not sent to any message

consumer. However, unless the connection to the server has
been terminated, the publishing application will not receive
any exceptions, despite the fact that no consumer received
the message.

EMS Delivery Modes Reviewed

NON_PERSISTENT and RELIABLE_DELIVERY messages are

never written to persistent storage.

PERSISTENT messages are written to persistent storage

when they are received by the EMS server.

PERSISTENT Mode Revisited

EMS Persistent Mode Management

Persistent Messages Sent to Queues

Persistent messages sent to a queue are always written to disk.
Should the server fail before sending persistent messages to
consumers, the server can be restarted and the persistent
messages will be sent to the consumers when they reconnect to
the server.
TIBCO EMS Server

Message
Producer

Queue
Send Message

Receive Message

Acknowledge

Disk

Message
Consumers

EMS Persistent Mode Management

Persistent Messages Sent to Topics

Persistent messages published to a topic are written to disk
ONLY IF that topic has at least one durable subscriber or
one subscriber with a fault-tolerant connection to the
EMS server.

Non-durable subscribers that re-connect after a server failure

are considered newly created subscribers and are not
entitled to receive any messages created prior to the time they
are created.

EMS Persistent Mode Management

Other
Consumers

TIBCO EMS Server

Subscribe to Topic

Message
Producer

Topic
Subscribe to Topic

Publish Message

Durable
Consumers

Subscribe to Topic

Store

Fault
Tolerant
Consumers

Persistent Messages & Synchronous Storage

When using file storage, persistent messages received by the

EMS server are by default written asynchronously to disk.

When a producer sends a persistent message, the server

does not wait for the write-to-disk operation to complete
before returning control to the producer.

This means that the producer has no way of detecting the

failure of persisting the message and take corrective action
if the server fails before completing the write-to-disk
operation.

Persistent Messages & Synchronous Storage

What do you do if you want to SYNCHRONOUSLY write to disk?

You can set the mode parameter to sync for a given file
storage in the stores.conf file to specify that persistent
messages for the topic or queue be synchronously written to
disk.

When mode = sync, the persistent producer remains blocked

until the server has completed the write-to-disk operation.

STORE

Store
EMS Server

Define
STORES
Stores.conf

WRITES TO

Pre allocate disk space for

store file

File-based Store
Properties that
(Default)
allow the user to
control how
server manages
the store file

Database Store

Truncate the file to relinquish

disk space
Mode : Sync or Async
Store messages in DB or not

Default Store Files

File based stores are enabled by default.

Server automatically defines 3 default stores

$sys.nonfailsafe

Server writes messages using asynchronous I/O calls.

$sys.failsafe

Server writes messages using synchronous I/O calls.

$sys.meta

Server writes state information about durable subscribers & fault

tolerant connections.

Message COMPRESSION

Message Compression

TIBCO Enterprise Message Service allows a

client to
compress the body of a message before sending the message
to the server.

EMS supports message compression/decompression across

client types (Java, C and C#). For example, a Java producer
may compress a message and a C consumer may decompress
the message.

Message compression is supported in .NET clients when using

the install package for Visual C++ 8 / .NET 2.0 or above.

Message Compression

Less memory storage for PERSISTENT queue messages or

DURABLE topic subscribers.

Compression option only compresses the BODY content.

Headers and properties are NEVER compressed.

When messages are not stored, compression is not a good

option. Why?

Because, Compression takes TIME!

Message Compression

Compression specific for individual messages.

Not on a per-queue or per-topic basis.

To set message compression

JMS_TIBCO_COMPRESS to TRUE

Message ACKNOWLEDGEMENT

Message Acknowledgement
Message

Message
Producer

Message

TIBCO EMS
Confirmation

Acknowledgement

Server

Message
Consumer

Confirmation of
Acknowledgement

JMS

EMS (JMS + Below mentioned modes)

CLIENT_ACKNOWLEDGE

NO_ACKNOWLEDGE

AUTO_ACKNOWLEDGE

EXPLICIT_CLIENT_ACKNOWLEDGE

DUPS_OK_ACKNOWLEDGE

EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE

JMS : CLIENT_ACKNOWLEDGE

Consumer is to acknowledge all messages that have been

delivered so far by the session.

Possible for the consumer to fall behind in its message

processing and build CONSUMER
up a large number of unacknowledged
messages

ACKNOWLEDGES

Message 3
1
2

Message
Producer

Message 2
1
3

TIBCO EMS
Server

Acknowledgement
# 1,2,3

Message
Consumer

JMS : AUTO_ACKNOWLEDGE

Session is to automatically acknowledge consumer receipt of

messages when message processing has finished

Message 3
1
2

Message
Producer

SESSION

Message 2
1
3

TIBCO EMS
1
3
Acknowledgement 2
ACKNOWLEDGES
Server

Message
Consumer

JMS : DUPS_OK_ACKNOWLEDGE

Session is to "lazily" acknowledge the delivery of messages to

the consumer.

"Lazy" means that the consumer can delay acknowledgement

of messages to the server until a convenient time;
meanwhile the server might redeliver messages.
LAZY
ACKNOWLEDGEMENT

Message 3
1
2

Message
Producer

Message 2
1
3

TIBCO EMS
Server

Acknowledgement
#1,2
#3

Message
Consumer

EMS : NO_ACKNOWLEDGE

NO_ACKNOWLEDGE mode suppresses the acknowledgement

of received messages.

After the server sends a message to the client, all

ssions cre
a t e dmessage
i n n o - for that consumer is
informationS eregarding
that
acknowledge receipt mode
eliminated from
the server.
cannot be used to create
cannot be used to create
durable subscribers.

Therefore, there is no need for the client application to

send an acknowledgement to the server about the received
message.

EMS : EXPLICIT_CLIENT_ACKNOWLEDGE

EXPLICIT_CLIENT_ACKNOWLEDGE is like CLIENT_ACKNOWLEDGE

except it acknowledges only the individual message, rather than
all messages received so far on the session.

Message
Producer

CONSUMER
Message 3
1ACKNOWLEDGES
2
Message 2
1
3
TIBCO EMS
INDIVIDUALLY
1
Acknowledgement 2
3
Server
Server

Message
Consumer

EMS : EXPLICIT_CLIENT_ACKNOWLEDGE

When
EXPLICIT_CLIENT_ACKNOWLEDGE
would be used ?

When we receive the messages and put their information in

a database and if the database insert operation is slow, you
may want to use multiple application threads all doing
simultaneous inserts.

As each thread finishes its insert, it can use this mode to

acknowledge only the message that it is currently working
on.

EMS : EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE

EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE is
like DUPS_OK_ACKNOWLEDGE except it lazily
acknowledges only the individual message,
rather than all messages received so far on the
session.

Message SELECTORS

Message Selectors

A message selector is a string that lets a client program

specify a set of messages, based on the values of message
headers and properties.

A selector matches a message if, after substituting header

and property values from the message into the selector
string, the string evaluates to true.

Consumers can request that the server deliver only those

messages that match a selector.

Destinations

Types of Destinations

Static Destinations

Dynamic Destinations

Temporary Destinations

Static Destinations

Purpose

Scope of delivery

Supports concurrent use

Creation

Allows administrators to configure EMS behavior at enterprise level

Using config files, tibemsadmin or by APIs by administrator

Duration

Until explicitly deleted by the administrator

Dynamic Destinations

Purpose

Provide flexibility to define them as needed for short term use

SERVER

Scope of delivery

Supports concurrent use

Creation

OFFLINE
DURABLE
SUBSCRIBER

Queue

Topic

Client programs create it DYNAMIC

if permitted by server configuration
DESTINATION

Duration

As long as at least 1 client actively uses it

Temporary Destinations

Purpose

Scope of delivery

Supports local use

Creation

Ideal for limited scope usage, like reply subjects (in routing)

Client programs create it

Duration

Explicit deletion by the client or disconnection from the server

Mixed Bag - Destinations

Clients can obtain references to static destinations through a

naming service such as JNDI or LDAP

But they cannot obtain the references to dynamic or temporary

destinations

Dynamic topics and queues have an asterisk (*) marked in front of

them, when you use the commands show queues or show topics in
tibemsadmin

If a property of a queue or topic has an asterisk (*) character in

front of its name, it means that the property was inherited from
the parent queue or topic

TIBCO EMS JNDI Basics, Concepts and

Usage

What is JNDI

Java Naming and Directory Interface is an API for accessing

naming and directory services.
Naming Service allows to lookup an object by a given
name.
Directory Service allows to lookup an object and fetches its
attributes or search an object based on its attributes.
JNDI is mainly used to perform below operations on Objects
Binding: Assigning name to an object or storage of object
to a name is called Binding and the name is called JNDI
name.
Look Up: Retrieving or calling an object using JNDI name.

JNDI Basics

The Context interface plays a central role in JNDI. A context represents a set of
bindings within a naming service that all share the same naming convention. A
Context object provides the methods for binding names to objects and unbinding
names from objects, for renaming objects, and for listing the bindings.

JNDI performs all naming operations relative to a context. To assist in finding a

place to start, the JNDI specification defines an InitialContext class. When you
use JNDI, you typically create an InitialContext object first. This class is
instantiated with properties that define the type of naming service in use and,
for naming services that provide security, the ID and password to use when
connecting.

JNDI Service Providers

JNDI service provider enables the clients to perform JNDI operation on

objects.

Different service providers are available to implement the Binding and

Look up operations.

Few of them are:

LDAP (Light weight Directory Access Protocol),
RMI (Remote Method Invocation),
NIS (Network Information Service),
DNS (Domain Name System),
File Server, etc.

Clients use JNDI API for connecting to different JNDI service providers for
binding and look up operations.

TIBCO EMS Objects

TIBCO EMS provides 4 types of Objects. Binding and Lookup
operations can be performed on these objects.
1.
2.
3.
4.

Queue Connection Factory

Topic Connection Factory
Queue
Topic

EMS JNDI Service Provider

TIBCO EMS provides the ability to bind and lookup EMS

objects using EMS server as the JNDI service provider.
EMS JNDI service provider can be accessed at the same port
where EMS server is installed, using JNDI context URL
JNDI Context URL Syntax: tibjmsnaming: //hostname: port
Tibjmsnaming: EMS JNDI communication protocol
Hostname and port: EMS server hostname and port.

The flow between BW JMS connection, EMS

JNDI service provider and EMS Server

Binding the JNDI name to Queue/Topic

connection Factories

A connection factory is an object that is used to define a client connection. EMS

clients use the connection factories for connecting to Queues/Topics in the
server.

Create a Queue connection factory QCF using EMS admin tool or directly in the
factories.conf file.

Connection factory can be created by providing the factory type and URL for EMS
server as below:
[QCF]

type

= queue

url

= tcp://7222

This Queue Connection factory binds to the JNDI name QCF. EMS clients use
this JNDI name to connect to local host EMS Queues.

Note: By default the url takes the local host if it is not specified. We can even give the
connection factory url to another EMS server, then this JNDI name connects to that servers
EMS queue.

Lookup the JNDI name of Queue/Topic

connection factories

Tibco

Server

Configurations

(EMS)

CONFIGURATION FILES IN TIBCO

Config File

Path

Description

Values

tibemsd.conf

/app/tibco/config/ems/7222

This file has different parameters which control characteristics of Tibco JMS
Server

This has many parameters as listed in Table 2

This File will have all the user information in following format

tibco_user1:password1:"ft communication user"

<username><password>:description

Tibco_EMS_User:password2:"Used for external application authentication to the

esb"
anonymous::"Used for external application authentication where that application
does not use a password"
users.conf

queue.conf

acl.conf

/app/tibco/config/ems/7222/common

/app/tibco/config/ems/7222/common

/app/tibco/config/ems/7222/common

Tibco_monitor:password3:"ovo monitoring user"

This file contains list of all the queues associated with the server and, it also
describes properties associated with each queue

example:

<queue name > <property 1> <property 2>

ServiceDelivery.VSS.StartMigrateTN.Response.Application1 maxRedelivery=3

This file contains information as which user has what access on which
destination , the format of the file is

ADMIN USER=admin PERM=view-all

<Destination Type>=<destination name > USER=< user> PERM= <access

list>

ADMIN USER=monitor123 PERM=view-all

Example:
[topic:ServiceDel.VSS.StartMigrateTN.Response]

bridges.conf

/app/tibco/config/ems/7222/common

Bridge between topic,queue

/app/tibco/config/ems/7222/common

This file defines routes between this TIBCO EMS server and other TIBCO EMS
servers

queue=ServiceDel.VSS.StartMigrateTN.Response.Application1
[TIBCO_LAB]

routes.conf

url = tcp://10.101.95.115:7222
[ESBQueueConnectionFactory]
type= queue

factories.conf

/app/tibco/config/ems/7222/common

This file defines the connection factories in the internal JNDI.

url= tcp://tibco01.organisation.com:7222,tcp://tibco02.organisation.com:7222

tibemsd TIBCO EMS Server

Starting the EMS Server

Running this

W H AT I F t i b e m s d . c o n f I S
L O C ATE D I N S O M E O T H E R
FOLD
ER?
service
starts
the EMS Server

This service starts tibemsd.exe located in

<EMS HOME>/bin folder
tibemsd.exe reads tibemsd.conf for server settings

tibemsd.conf file has many parameters which

defines the configuration for the ems servers
Parameters

Description

Values (tibco01.prod)

Server Identification
information

Unique Server name and

password to login to other
routed server

server
= TIBCO_Server_Name
password = password123

Configuration files

Contains path for all config

files

/app/tibco/config/ems/7222/users.conf

store

directory to store persistent

messages

/
app/tibco/shared/data/ems/7222/datasto
re
asyncmsgs_store.db,meta_store.db,syncmsgs_store.db

Listen ports

information about port and

protocol used by server

tcp://tibco01.organisation.com:7222

authorization

User credentials

logfile
ft_active

Log file name for ems

Fault tolerant setup

Enabled
/app/tibco/log/tibco_ems_data.log
tcp://tibco02.organisation.com:7222

Using tibemsd to start EMS server

CAUTION
1. N e e d t o c r e a t e s t o r e s ( . d b
files) manually in
tibemsd.conf.
2. Need to specify the
directory for other config
files(default : bin folder)
in tibemsd.conf

tibemsadmin TIBCO EMS Admin

Starting tibemsadmin

Using connect

Using help

Using disconnect

Using exit

Using shutdown

Using show

Using create

Using delete

Using addprop

Using removeprop

Using setprop

Using purge

Using whoami & info

show server

Using set

Parameters in tibemsd.conf

Using time & timeout

Using commit & autocommit

Using compact

Using add

Using remove

Using grant & revoke

Using echo

Destination PROPERTIES

channel

channel

Channel property determines the multicast channel over which

messages sent to the topic are broadcast

Configure multicast channels in channels.conf file and enable this

feature in tibemsd.conf

Cannot create channel by any command in tibemsadmin

Only 1 channel allowed for each topic

Available only for topics

channel
tibemsd.conf

channels.conf

channel

exclusive

exclusive

Available only for queues

Set the exclusive property using addprop or setprop

When exclusive is set for the queue, the server sends all the
messages on that queue to one consumer. No other consumer can
receive messages from the queue.

Instead, these additional consumers act in a standby role; if the

primary consumer fails, the server selects one of the standby
consumers as the new primary and begins delivering messages to it.

exclusive

expiration

expiration

If an expiration property is set for a destination, the server honors

the overridden expiration period

If expiration property for the server is set, the server overrides

the JMSExpiration value set by the producer in the message
header

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

expiration

maxbytes

maxbytes
Topics & queues can specify the maxbytes property in the form

maxbytes=value[KB|MB|GB]
FOR QUEUES

maxbytes: maximum size (in bytes) that the queue can store,
summed over all the messages in the queue

If this limit is exceeded, the messages will be rejected by the

server and the producer send calls will return an error

maxbytes
FOR TOPICS

maxbytes: maximum size(in bytes) that the topic can store for
delivery to each durable or non-durable online subscriber on that
topic

The limit applies separately to each subscriber on the topic

Example :
offline durable subscriber
exceed maxbytes

messages accumulate until they

non durable subscriber

maxbytes limits the number of
pending messages that can accumulate while the subscriber is
online

maxbytes

maxmsgs

maxmsgs
Topics & queues can specify the maxmsgs property in the form

maxmsgs=value

maxmsgs: maximum number of messages that can be waiting in a

queue

When adding a message into a queue/topic would exceed this limit,

the server would reject the message and the producers send call
returns an error

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

maxmsgs

maxRedelivery

maxRedelivery

The number of attempts the server should make to deliver a

message sent to a destination

maxRedelivery=count
count is between 2 & 255

For messages that have been redelivered,

JMSRedelivered header property is set to true

JMSXDeliveryCount property is set to the number of times the

message has been delivered to the destination

maxRedelivery

overflowPolicy

overflowPolicy

To change the effect of exceeding the message capacity established by maxbytes

or maxmsgs

overflowpolicy=default|discardOld|rejectIncoming

default
For TOPICS
maxbytes or maxmsgs exceed for a subscriber, that subscriber does not receive
message
No error returned to producer
For QUEUES
New messages are rejected by the server if maxbytes or maxmsgs are exceeded
Error returned to producer

overflowPolicy

discardOld
For TOPICS
Oldest messages are discarded before they are delivered to the subscriber

Impacts subscribers individually. 3 subscribers, 1 exceeds the message limit.

So, only the oldest messages for the one subscriber are discarded, while
other two continue to receive all messages

No error returned to producer, as message can be delivered to some and

discarded for others

For QUEUES
Error returned to producer if maxbytes or maxmsgs are exceeded

Oldest messages are discarded from the queue by the server

overflowPolicy

rejectIncoming
For TOPICS

If ANY of the subscribers have an outstanding number of undelivered

messages on the server that are over the message limit, all new
messages are rejected

Error is returned to producer

For QUEUES

Error returned to producer if maxbytes or maxmsgs are exceeded

Newest messages are rejected from the queue by the server

overflowPolicy

Quick Quiz

How do I discard messages on myQueue when the

number of queued messages exceeds 2500 ?
setprop queue myQueue maxmsgs=2500, overflowpolicy=discardOld

How do I reject all new messages published to

myTopic when the memory used by undelivered
messages for any of the topic subscribers exceeds 3
MB?
setprop topic myTopic maxbytes=3MB,overflowPolicy=rejectIncoming

flowControl

flowControl

Specifies the target maximum size the server can use to store
pending messages for the destination

If number of messages > flowControl

flowControl never discards
messages or generates
then

Unlike overflowPolicy,

error back to producer

slow down the producers to the rate required by the message
consumers

Useful when message producers send messages more quickly than

message consumers can consume them

flowControl
tibemsd.conf

prefetch

prefetch

Consumer and the EMS Server cooperate to regulate message

fetching through this property
prefetch=value
Value

Description

2 or more

Never fetches more than specified

number (Auto Fetch)

Fetch only if it has no message

(Auto Fetch)

none

Disable Auto Fetch.

Cannot be used with
topics or global queues

0 (default)

Destination inherits the prefetch value.

Default value for
queues = 5 & topics = 64

prefetch
prefetch = 5
Now, messages belong to consumer SERVER
5
4
3
2
1

CONSUMER

ERROR

$sys.undelivered

JMS_TIBCO_PRESERVE_UNDELIVERED = true

maxRedelivery = 4
JMSXDeliveryCount = 0
2
1
3
4
5
JMSRedelivered = false
true

prefetch

2 phases : messages from server to consumer

Fetch Phase

RECEIVE CALL

o Consumer

initiates fetch phase by sending a signal to the server

that it is ready for more messages

o Server

responds by transferring one or more messages and gets

stored in consumer

Accept Phase
o Client

code takes a message from the consumer

prefetch
Automatic Fetch Enabled (prefetch = positive integer)

Improves performance by decreasing or eliminating client idle

time while the server transfers a message

When a queue consumer prefetches a group of messages, the

server does not deliver them to other queue consumers (unless
the first queue consumers connection to the server is broken)

prefetch
Automatic Fetch Disabled (prefetch = none)

Even when prefetch = none, a queue consumer can hold a message

Example
A receive call initiates a fetch, but its timeout elapses before
the server finishes transferring the message
This leaves a fetched message waiting in the message

consumer

A second receive call does not fetch another message; instead it

accepts the message already waiting
The third receive call initiates another fetch

prefetch

A waiting message still belongs to the queue consumer, and the

server does not deliver it to another queue(unless the first queue
consumers connection to the server is broken)

To prevent messages from waiting in this state for long periods

Call receive with no timeout
Call receive with timeout repeatedly and shorten the interval
INHERITANCE
PARENT

CHILD

all parents : none

none

any parent :
non-zero numeric value

highest

does not set any value

default
(5 : queues, 64 : topics)

prefetch

secure

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

tibemsd.conf

sender_name

sender_name

Server may include the senders username for messages

sent to this destination

When connection between producer and server is

established, server takes the username supplied by the
producer and places it in the JMS_TIBCO_SENDER
property of the message

But if producer sets the JMS_TIBCO_DISABLE_SENDER to

true for a message, server will not add the sender
name to the message

sender_name

sender_name_enforced

sender_name_enforced

Specifies that the messages sent to this destination

MUST include the senders username

Unlike sender_name property, there is no way for

message producers to override this property

This property overrides sender_name if already set.

sender_name_enforced

store

store

Specifies where the messages sent to this

destination are stored

Configure stores in stores.conf

Stores.conf
> store = myStore
testTopic store = topicStore

Destination BRIDGES

Bridges

Some applications require the same message

to be sent to more than one destination,
possibly of different types.
Example
An application can publish messages to several topics.
All messages however, must also be sent to a database
for backup and for data mining. A queue is used to
collect all messages and send them to the database.

Bridges

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.

Bridging Topic to Queue

TIBCO EMS SERVER
Subscriber
Publisher

Topic
Topic
A.B
A.B

Subscriber
Queue
Queue
queue.B
queue.B
Consumer

Bridging Topic to Multiple Destinations

TIBCO EMS SERVER
Subscriber
Topic
Topic
A.B
A.B

Publisher

Subscriber
Queue
Queue
queue.B
queue.B
Consumer

Topic
Topic
C.B
C.B
Subscriber

Bridging Queue to Multiple Destinations

TIBCO EMS SERVER

Sender

Queue
Queue
queue.foo
queue.foo

Consumer

Subscriber
Queue
Queue
queue.B
queue.B
Consumer

Topic
Topic
C.B
C.B
Subscriber

Bridges

When a bridge exists between two queues, the

message is delivered to both queues. The queues
operate independently; if the message is
retrieved from one queue, that has no effect on
the status of the message in the second queue.

Bridges are not transitive

Topic A.B has a bridge to queue Q.B. Queue Q.B has a
bridge to topic B.C. Messages delivered to A.B are also
delivered to Q.B, but not to B.C.

Creating a bridge

Configured in bridges.conf file

Bridges.conf
[topic:A.B]
queue=queue.B
topic=C.B
selector="urgency in(medium, high)"

Use of Selector
All messages sent to a destination with a bridge are sent to
all bridged destinations. This can cause unnecessary network
traffic if each bridged destination is only interested in a
subset of the messages sent to the original destination.

ROUTING

Routing

EMS 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

and from the home queue

Routing : Basic Operation

Each route connects two TIBCO EMS 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.

Routing : Hawk Eye View

Server : A

ROUTE

Server : B

Queue : Q1

Queue :
Q1@A

Topic : T1

Topic : T1

G L O B A L TOP I C

G L O B A L TOP I C

Topic : T2

Global Destinations : Topics

Routes forward messages only between global destinations
Server : A

Server : B
Topic : T1

Topic : T1

G L O B A L TOP I C

G L O B A L TOP I C

Topic : T2

Topic : T2
G L O B A L TOP I C

For TOPICS, the global property must be set on both servers

Unique Routing Path

It is illegal to define a set of routes that permit a message to

reach a server by more than one path. TIBCO EMS servers detect
illegal duplicate routes and report them as configuration errors.
A

LEGAL
(in all zones)

ILLEGAL
(in a multihop zone)

Zones

A zone is a named set of routes.

Every route belongs to a zone.

Zones restrict the behavior of routes, so you

can configure complex routing paths.

Zones affect topic messages, but NOT queue

messages.

Zones : Basic Operation

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.
A
If a message is sent to
the global topic on
If Z1 were a one-hop
server B, the server
zone, B would forward
forwards the message to
the message to A, C & D,
A,C,D,E provided there
but not to E
are subscribers on those
servers

Zone : Z1
mhop

Eliminating Redundant Paths with One-Hop Zone

B1

B2

B1 & B2 : Producers @ Branch Office

M : Consumers @ Main Office
R : Consumers @ Back Office

M serves consumers that process the

message from branches B1 & B2

Zone : Z2
1hop

R serves consumers that record

messages for archiving, auditing &
backup

GOAL : Forward messages from B1 and B2 to both M and R

Overlapping Zones
M3

M4
Zone : Mumbai
1hop

M2

M1

Zone : India
mhop

D1

D2

D4

D3

B2

B3

B1

B4
Zone : Bangalore
1hop

Zone : Delhi
1hop

Creating Routes
Syntax
create route EMS-SERVER url=tcp://ipserver:7222
zone_name=zoneName
zone_type=1hop|mhop
route name MUST be the name of the EMS server
which is specified in tibemsd.conf
url indicates the other server by the URL

Active & Passive Routes

A route connects two servers.

You may configure a route at either or both of the servers.

A route is active from the perspective of the server where it is

configured. This server actively initiates the connection to the
other server, so we refer to it as the active server, or initiating
server.

A route is passive from the perspective of the other server. This

server passively accepts connection requests from the active
server, so we refer to it as the passive server.

Active Active Routes

Two servers can both configure an active route one to the other.
This arrangement is called an active-active configuration.
For example, server A specifies a route to server B, and B specifies a
route to A. Either server can attempt to initiate the connection. This
configuration results in only one connection; it does not result in
redundant routes.

You can promote an active-passive route to an active-active route

by using this command on the passive server

create route name url=url

The url argument is required, so that the server (where the route
is being promoted) can connect to the other server if the route
becomes disconnected

Routed Topic Messages

A server forwards the message along the

routes only when the global property is
defined by the topic

Routed Topic Messages

Topic messages can traverse multiple hops.

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.

Servers connected by routes do exchange messages

sent to temporary topics.

Routing : Propagating Subscribers

A

Zone Z

mhop
Server A

Server M

Server B

Topic : T1

Topic : T1

Topic : T1

GL O B AL TOP I C

G L O B A L TOP I C

GL O B A L TOP I C

Subscriber : T1

Subscriber : T1

Subscriber : T1

CLIENT

CLIENT

Producer : T1

Subscriber : T1

Routed Queues
How is routing in queues different from that in
topics?

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

Routed Queues

In routing topics, the declaration of the topic

is identical on all servers

Queue declarations make a distinction

between the server that owns the queue and
other servers with routed queues that
reference both the queue name and the
owning server

Routed Queues
P

Server P
Q1 @ R :
global
Store & forward
to R

Server R
Q1 : global
The message is NOT
available for consumers
HOME
QUEUEthe
until
it reaches
HOME QUEUE

Proxy Receiver

Server S
Q1 @ R :
global

Proxy Receiver

Producer A

Consumer B

Consumer C

Consumer D

Q1

Q1

Q1

Q1

Routed Queues

Routed queues serve as proxies for the real

queue

Messages published to the proxy queue are

forwarded to the real queue, and are not
eligible for delivery until they reach the real
queue

EMS Fault Tolerance

EMS Fault Tolerance Overview

You can arrange TIBCO Enterprise Message Service servers

for fault-tolerant operation by configuring a pair of servers
one primary and one backup.
The primary server accepts client connections, and interacts
with clients to deliver messages. If the primary server fails,
the backup server resumes operation in its place.

Shared State and Locking

A pair of fault-tolerant servers must have access

to shared state, which consists of information
about client connections and persistent
messages. This information enables the backup
server to properly assume responsibility for
those connections and messages.
To prevent the backup server from assuming the
role of the primary server, the primary server
locks the shared state during normal operation.
If the primary server fails, the lock is released,
and the backup server can obtain the lock.

Implementating Shared State

You implement shared state using shared

storage devices. The shared state must be
accessible to both the primary and backup
servers.
Consider the following hardware options for
shared storage:
Storage Area Network (SAN)
Network Attached Storage (NAS)

Implementating Locking

The EMS servers must be able to request and obtain an

exclusive lock on the shared storage.

On UNIX platforms, servers use the standard fcntl operating

system call to implement cooperative file locking.
UNIX variants differ in their implementations.

EMS has no file locking mechanisms inherently. It relies on

the OS to correctly respond to the fcntl API.

On clustered file systems the distributed lockingis taken

care of by the clustering software.