TIBCO EMS STEP -10 : Store Types

-

Ø  The EMS server can write messages to different types of stores: file-based stores, mstores, and database stores.
Ø  File-Based Stores: The EMS server stores persistent messages in file-based stores. We can create own file-based stores. We need to direct the EMS server to write messages to these store files by associating a destination with a store.
Ø  File-based stores are enabled by default, and the server automatically defines three default stores.
Ø  The mstore is designed to recover quickly after a failover. When mstores are in use, the EMS server starts quickly, but may run more slowly until the mstore cache is fully loaded and discards stale data, such as purged and expired messages.
Ø  database stores :The EMS server can store messages in one or more database instances. Database stores must be configured to use a supported database.
Default Store Files
Ø  The EMS server defines these default store files, and writes persistent messages and meta data to them.
Ø  $sys.nonfailsafe—Persistent messages without a store property designation are written to $sys.nonfailsafe by default. The server writes messages to this store using asynchronous I/O calls.
Ø  $sys.failsafe : The server writes messages to this store using synchronous .
Ø  $sys.meta: The server writes state information about durable subscribers, fault-tolerant connections, and other metadata in this store.





Above diagram describes the steps in message delivery and acknowledgement:
Ø  1. A message is sent from the message producer to the machine on which the EMS server resides.
Ø  2. For persistent messages, the EMS server sends a confirmation to the producer that the message was received.
Ø  3. The server sends the message to the consumer.
Ø  4. The consumer sends an acknowledgement to the server that the message was received. A session can be configured with a specific session mode that specifies how the consumer-to-server acknowledgement is handled. These session modes are described below.
Ø  5. In many cases, the server then sends a confirmation of the acknowledgement to the consumer.









Comments

Post a Comment

Popular posts from this blog

TIBCO EMS FAQ -5

-
131) 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. 132) What are the wild cards that we use in ems?how do they work for queues and topics? *,> We can subscribe to wildcard topics, but cant publish to them. Where as in case of queues we can’t either send /receive. 133) Are bridges transitive? No 134) Tell me about flow control on destinations? Sometimes 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. 135) 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. 136) Nam...
Read more

TIBCO EMS FAQ -4

-
101) What are the permissions that you can grant to users to access topics? a. Subscribe b. Publish c. Durable d. Use durable 102) 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. 103) 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. 104) 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 re...
Read more

TIBCO BW FAQ -2

-
31) What happens if you use check point activity first and confirm next? Ans)In the case of confirmable messages , you must consider the consequences of performing a checkpoint before or after a Confirm activity. If the checkpoint is taken before the Confirm activity, then a crash occurs after a checkpoint but before a confirm, the original message is resent. In this case, the restarted process can no longer send the confirmation. However, a new process is started to handle the resent message, and you can implement your process to handle the restarted and new processes appropriately. If the checkpoint is taken after a Confirm activity, there is potential for a crash to occur after the Confirm but before the checkpoint. In this case, the message is confirmed and therefore not redelivered. The process instance is not restarted, because the crash occurred before the checkpoint. You must consider the type of processing your process definition performs to determine when a checkpoint i...
Read more