EMS

Define Messaging Models supported by EMS.
EMS supports three Messaging models.
1. Point to Point (Queue)
2. Publish-Subscribe (Topic)
3. Multicast (Topic)

Describe Queues functionality.

• Queue represent Point to Point communication model, in this model, the message sent by Producer("Queue Sender") is can only be consumed by one Consumer ("Queue Receiver") at any given time. However, many consumers can can listen on to the same queue but no two consumers can consume same message at all.
• Point to Point Model delivers the messages in a Round-Robin fashion, meaning that when multiple consumers are retrieving the messages from queue, the messages will be delivered to only one consumer at time and the next message will be deliver to the next consumer and so on.
• You can configure to override the queue's Round-Robin delivery of messages by means of "Exclusive". When you define a queue as exclusive, only the first consumer will receive all the messages, reaming consumers cant retrieve.

Can multiple Producers send messages to the same Queue?

Yes. Many producers can send messages to same queue and Many receivers can retrieve messages from same queue.

How do you load Balance the messages across multiple receivers?

By default, having multiple receivers is a load balanced as the messages will delivered in Round-Robbin.

When producer sends a msg to a queue and the consumer is not active, will consumer receive the msg when it become active?

Yes.

How long the msg for Queue Receiver is stored on server when it's not active.

1. Until the msg expires OR

2. Until the maxRedelivery 
then it moves the msg to the $sys.undeliverd system queue only if JMS_TIBCO_PRESERVE_UNDELIVERED property for the msg is set to true, else it will just delete the msg.

Describe Topics functionality.

• Topic represent Publish-Subscribe communication model. In this model, the message published by Producer("Topic Publisher")can be consumed by all the Consumers ("Topic Subscriber"). 
• This model is also know as "Broadcast" messaging.
• Many publishers can publish to the same topic, and a message from a single publisher can be received by many subscribers. Subscribers subscribe to topics, and all messages published to the topic are received by all subscribers to the topic.

When Publisher publishes a msg to a topic and the subscriber is not active, will subscriber receive the msg when it become active?

No. by default, subscribers receive msgs only when they are active. 

What is Durable Subscription?

Defining Durable Subscriber for a topic, it ensures that the msgs are received by the subscriber even if the subscriber is not active when msgs published. Msg will be stored on server and will delivered when the subscriber become active.

How long the msg for Durable Subscriber is stored on server when it's not active.

1. Until the msg expires OR

2. Until Storage Limit  reached for that topic OR

3. As long as the subscription for that topic exist.

Define JMS Message structure.
JMS includes three sections.
Header
Properties
Body

Can we exclude "Body" section from a JMS message when sending/Publishing?
Yes. "Body" and "Properties" sections are optional & can be excluded but the "Header" section is required so cant be left empty. 

Can we use any Message Type to leave the Body section empty?
No. To leave "Body" section to be empty the "Message Type" should be "Simple".

List the JMS Message Header Fields.

JMS Message Headers are configured in the "Configuration" and "Advanced"  or "Input" section of a Sender/Publisher JMS activities.

JMSDestionation

Queue/Topic

JMSDeliveryMode

Persistent/Non-Persistent/Reliable

JMSExpiration

Length of time the msg will live. "0" indicates no expiration

JMS DeliveryTime

Time when EMS server will deliver the msg to the consumer

JMSPriority                   

0 to 9, higher the number higher the priority

JMSMessageID               

Value uniquely identifies each message sent by a provider.

JMSTimestamp             

Time stamp of time when message was handed off to a provider to be sent.

JMSCorrelationID         

This ID can be used to link msgs, such as linking a response msg to a request msg.

JMSReplyTo                  

A destination to which a msgreply should be sent. Entering a value for this field is ptional.

JMSType 

Message type

JMSRedeliverd             

true/false-Indicates if the msg is redelivered

Are all the JMS Header fields are settable by sender/publisher method?
No, Not all the header fields, some of the fields are settable by 'message client' and 'JMS provider'. Refer below list:

Set By send or Publish method
JMSDestionation
JMSDeliveryMode
JMSExpiration
JMS DeliveryTime
JMSPriority
JMSMessageID
JMSTimestamp

Set by Message Client
JMSCorrelationID
JMSReplyTo
JMSType

Set by JMS provider
JMSRedeliverd

List the EMS Message Properties.
The properties are optional but can be set by defining them in the "JMS Application Properties" activity and mapping to the send/publish activities.

JMS_TIBCO_CM_PUBLISHER

JMS_TIBCO_CM_SEQUENCE

JMS_TIBCO_COMPRESS

JMS_TIBCO_DISABLE_SENDER

JMS_TIBCO_IMPORTED

JMS_TIBCO_MSG_EXT

JMS_TIBCO_MSG_TRACE

JMS_TIBCO_PRESERVE_UNDELIVERED

JMS_TIBCO_SENDER

JMS_TIBCO_SS_SENDER

Whats the Maximum Message Size for EMS?
512 MB. Best practice is to use smaller msg to avoid performance issues.

Describe Delivery Modes

Persistent: EMS server writes the msg to disk before delivery it to the Consumer & Producer waits for confirmation receipt.

Non-Persistent: EMS server never writes to the disk and producer wont wait for the confirmation reply considering Authorization=Disabled and npcheck_send_mode=never.

Reliable: EMS server never writes to the disk and never sends a confirmation receipt.

Explain how Authorization & npcheck_send_mode will affect Non-Persistent delivery mode?
Authorization:
For a Non-Persistent delivery mode when Authorization=Enabled, the producer of the msg will wait for confirmation receipt just as in case of Persistent Delivery Mode.

For a Non-Persistent delivery mode when Authorization=Disabled, the producer of the msg will NOT wait for confirmation receipt & avoids the overhead.

npcheck_send_mode:
Regardless of whether authorization is enabled or disabled, you can use the npsend_check_mode parameter in the tibemsd.conf file to specify the conditions under which the server is to send confirmation of NON_PERSISTENT messages to
the producer.
npsend_check_mode = [always | never | temp_dest | auth | temp_auth]

Is Persistent Delivery mode behaves same for Queues & Topics?
No, behavior is different.
Queues:
Server always persist the msgs to disk.
Topics:
Server persist the msgs to disk only if that topic has at least one Durable subscriber or one subscriber with a Fault Tolerance connection to the EMS Server.


What happens to the msg if the server fails before writing persistent msg to disk?

Msg will be lost, there is no way to recover it. By default server doesn't wait for write-to-disk operation to complete (Persistent msgs are written to disk Asynchronously). This default behavior can be override by setting mode=sync in the stores.conf file.

What are the different stores in EMS?

EMS server defines below default stores.

$sys.meta (meta.db)

The server writes state information about durable subscribers, fault-tolerant connections, and other metadata in this store

$sys.failsafe (sync-msgs.db)

Persistent msgs are written to this store for the destination using store=$sys.failsafe.

$sys.nonfailsafe (asyn-msgs.db)

Persistent msgs are written to this store by default.

What is default store for Queues and Topics?

When a queue or topic is create, by default it uses store=$sys.nonfailsafe & persistent msgs for these queues/topics are written to asyn-msgs.db

What are the different stores Types in EMS?

File-Based Stores

mstores

Data-Based Stores

By default EMS uses Files-based store to write persistent messages.

Describe Message Compression.

• Message compression is useful in reducing the memory space in storage.
• This feature should be used if message body is large & will be stored on server.
• Compression usually takes longer time than uncompressed.
• Compression option only compresses the body of a message but not headers.
• Compression can be set using JMS_TIBCO_COMPRESS EMS property.
• Message compression is set per message level, cannot be set per Queue/Topic Level.

List Destination Properties.
channel
export 
exclusive
maxRedelivery   
redeliveryDelay  
expiration  
flowControl  
global  
import  
maxbytes  
maxmsgs  
overflowPolicy  
prefetch
secure
sender_name
sender_name_enforced
store
trace
Properties in BLUE applicable to Topics Only & Properties in Orange applicable to Queues Only. Properties in WHITE applicable to both Queues &Topics.

Which two destination properties are defaulted when Queue/Topic is created.
Prefetch and Store properties are assigned by default.
Prefetch =5 for Queues and Prefetch=64 for Topics.
Store=$sys.nonfailsafe for both Queues & Topics.

Describe Wild Cards in EMS.

* and > are two wild cards in TIBCO EMS. Use of each of this explained below
Wild Card ">"
The wildcard > by itself matches any destination name.
Meaning when you just search queues and/ or topic just by >, it will list list all queues/topics ( it is just same as Show Queues/Show Topics command)
Show queues >
Show topics >

When > is mixed with text, it matches one or more trailing elements.
Meaning when a search is made with first part of the queue/topic name text, it will list all which matches this text.

Example: Existing Queues are
queue.1
queue.sample
queue.sample.1
queue.sample.2

show queues queue.> 
it will list all above queues

Wild Card "*"
The wildcard * means that any token can be in the place of *.

Example: Existing Queues are
queue.1
queue.sample
queue.sample.1
queue.sample.2

show queues queue.*
it will list only one trailing matched elements.

Explain the steps involved in creating a secure queue and allowing only one user to send/receive msgs?

1. Create a queue
2. Create User
3. Enable "Authorization" property for the server.
4. Add "Secure" property to the queue
5. Grant permission to the queue

Note: "Secure" property will not be in effect if the server authorization is disabled.

Explains Authorization.

Authorization acts a master switch for validating user authentication and checking permissions on secured destinations.

If Authorization is disabled any user is allowed to connect to the server (ems connection will be successful even if incorrect password has been passed) and any user can send or receive msg to/from destinations. To enforce proper connection and permission validation "authorization" must be enabled.

How often does EMS server reads the configuration files?
EMS server reads configuration file only once when it starts. In order to make any changes done in configuration files to be current you must restart the server.