Creating Static Durable Subscriber for TOPIC

Tibco EMS FaultTolerence Configuration

We can configure EMS servers as primary and backup servers to provide fault tolerance for our environment. The primary and backup servers act as a pair,with the primary server accepting client connections and performing the work of handling messages, and the secondary server acting as a backup in case of failure.When the active server fails, the backup server assumes operation and becomes the new primary active server.When Server 2 becomes the new primary server, Server 1 can restart as a backup server, so that the two servers exchange roles.

Tibco do not support more than two servers in a fault-tolerant configuration.

                                                  

backup server detects a failure of the primary in either of two ways:

• Heartbeat Failure —The primary server sends heartbeat messages to the backup server to indicate that it is still operating. When a network failure stops the servers from communicating with each other, the backup server detects the interruption in the steady stream of heartbeats. 

• Connection Failure —The backup server can detect the failure of its TCP connection with the primary server. When the primary process terminates unexpectedly, the backup server detects the broken connection. 

When the primary server heartbeat stops, the backup server waits for its activation interval (elapsed time since it detected the most recent heartbeat); then the backup server retrieves information from shared storage and assumes the role of primary server. The default heartbeat interval is 3 seconds, and the default activation interval is 10 seconds. The activation interval must be at least twice the heartbeat interval. Both intervals are specified in seconds. We can set these intervals in the server configuration files.

Shared State:-

For the most robust failover protection, the primary server and backup server must share the same state. Server state includes three categories of information:

• persistent message data (for queues and topics)

• client connections of the primary server

• metadata about message delivery

During a failover, the backup server re-reads all shared state information.

Note :The Ems data store should be in SAN or NAS,in actual Production Environment..so that the datastore is accessible by both primary and back up server.
SAN-Storage Area Network

NAS-Network Area storage

But for our case we would use just operating system file system (shared by both primary and Backup server)

Fault Tolerance configuration setup:-

The below configuration setup will help you to run two EMS server instances In Fault Tolerance mode (servers run on different ports Say 7222,7333)

Creating Second server Instance:-

Create a folder called Server2  (say D:/Server2 ). In that copy all the configuration files(*.conf files ) from %TIBCOHOME%/ems/bin/

Now modify this tibemsd.conf (which is in Server2 folder)

Listen =tcp://localhost:7333



and Prepend this path to    D:\Server2\    below list in the  Sever2 tibemsd.conf

users=D:\Server2\ users.conf

groups=D:\Server2\groups.conf

topics=D:\Server2\ topics.conf

queues=D:\Server2\ queues.conf

acl_list=D:\Server2\ acl.conf

factories=D:\Server2\ factories.conf

routes=D:\Server2\ routes.conf

bridges=D:\Server2\ bridges.conf

transports=D:\Server2\transports.conf

tibrvcm=D:\Server2\queues.conf

durables=D:\Server2\durables.conf

Now you can run the server on port 7333 from CMD as shown in figure ( make sure that first server which is on port 7222 is stopped)

Starting server:- 

Server Status:-

Now we have two servers with same name EMS-SERVER. Now lets us make these two server to run as FT Pair.

Configuring Primary server(Server1)	Configuring Secondary server(Server2)
open the  C:\ProgramData\TIBCO\tibco\cfgmgmt\ems\data\tibemsd.conf  Server      =       EMS-SERVER Listen       =        tcp://localhost:7222 Ft_active  =        tcp://localhost:7333	open the                 D:\SecondEMSServer\tibemsd.conf     Server      =       EMS-SERVER Listen       =        tcp://localhost:7333 Ft_active  =        tcp://localhost:7222

Now we have created FT pair successfully.

now start the two servers from CMD.

The first started server will be active server

Start Backup server:-

once  backup server is started the you can see notification in the primary server 

If you stops the primary server (CTRL+C to stop server) then Server2 will became the new primary server.if sever 1 ups at any time it will be in standby mode

Creating  JMS Connection

A pair of URL's separated by a comma specifies a pair of fault-tolerant servers.

For example: tcp://host1:7222,tcp://backup1:7333

EMS scripting - How to execute a sequence of EMS commands

We can execute a sequence of EMS commands by writing a simple script file.

write EMS commands in txt file and save in some location for example   i saved my script file in the location C:\TEMP with name "script.scr" 
and its content is 

create queue prasanth
create topic  bandi
commit


in the script file every command must be contained on a single line (no line breaks within the command), and each command is separated by a line break

Now
open command prompt and go to the location C:\tibco\ems\5.1\bin and run the below command, it will execute the EMS commands

C:\tibco\ems\5.1\bin>
tibemsadmin -server "tcp://localhost:7222" -user admin -password "" -script C:\tibco\ems\5.1\bin\script.scr

just give the full path of the file with the extension(i.e C:\script.txt or C:\script.scr or C:\script.anything) in the command and run it.
Even if there is no file extension, it doesnt matter :-)...you just need to have a plain text file with all the ems commands. 

Syntax of the command is 

tibemsadmin -server <server-url> -user <user-name> -password  <password> -script C:\script.txt

Tibco EMS Destination Properties

Destination Properties

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

1)             Failsafe

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

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

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

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

2) Secure

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

·         If the secure property is not set for a destination, the server does not check permissions for that destination and any authenticated user can perform any operation on that topic or queue.
 Implementing Secure property:-
Enable authorization on server (you must restart server, If you are doing it through the conf files).Create two users, user1 and user2 for EMS server using Ems admin tool with the following command,

"Create user username password=<password>"
Connect to the server as admin and grant permission like send, receive only to user1.

"Grant queue sample user=user1 send, receive" 
Create the JMS connection with the users you created. 
Apply secure property to the any one destination for Example apply it to  'sample' queue

"addprop queue sample secure" 
now send message onto to secured sample destination once as user1 and once as user2. As authorization is enabled, server will check the user permissions, As user1 has privilege to send and receive messages so he can use the secured destination to send and receive  the messages but user2 don’t have any privileges so he can’t use secure destination for any purpose.If we disabled the authorization on server then user2 also use secured destination for any purpose.

3)Maxbytes

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

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

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

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

4) maxmsgs

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

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

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

5) OverflowPolicy

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

·         OverflowPolicy=default | discardOld | rejectIncoming

                                                I.        Default

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

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

                                                 II.     DiscardOld

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

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

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

                                              III.     rejectIncoming

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

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

6) global

·   Messages destined for a topic or queue with the global property set are routed to the other servers that are participating in routing with this server.

You can set global using the form:   global

7) sender_name

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

                     You can set sender_name using the form:    sender_name

8) sender_name_enforced

·   The sender_name_enforced property specifies that messages sent to this destination must include the sender’s user name. The server retrieves the user name of the message producer using the same procedure described in the sender_name property above. However, unlike, the sender_name property, there is no way for message producers to override this property.

                 You can set sender_name_enforced using the form:    sender_name_enforced

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

9) FlowControl

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

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

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

10) trace

·                     Specifies that tracing should be enabled for this destination.

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

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

11) import

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

You can set import using the form:    import="list"

12) export

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

You can set import using the form:    export="list"

·                     It supports for only topics not queues.

13) maxRedelivery

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

You can set maxRedelivery using the form:    maxRedelivery=count

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

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

Undelivered Message Queue

If a message expires or has exceeded the value specified by the maxRedelivery property on a queue, the server checks the message’s JMS_TIBCO_PRESERVE_UNDELIVERED property. If
JMS_TIBCO_PRESERVE_UNDELIVERED is set to true, the server moves the message to the undelivered message queue, $sys.undelivered. This undelivered message queue is a system queue that is always present and cannot be deleted. If JMS_TIBCO_PRESERVE_UNDELIVERED is set to false, the message will be deleted by the server.

14) exclusive

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

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

·         By default, exclusive is not set for queues and the server distributes messages in a round-robin—one to each receiver that is ready. If any receivers are still ready to accept additional messages, the server distributes another round of messages—one to each receiver that is still ready. When none of the receivers are ready to receive more messages, the server waits until a queue receiver reports that it can accept a message.

15) prefetch

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

You can set  prefetch using the form:  prefetch=value

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

Value Description

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

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

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

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

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

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

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

16) expiration                                                                                     

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

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

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

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