Questions on Tibco EMS
1.What are the extra features are available in EMS apart from JMS?
•The JMS standard specifies two delivery modes for messages, PERSISTENT and NON_PERSISTENT. EMS also includes a RELIABLE_DELIVERY mode that eliminates some of the overhead associated with the other delivery modes.
2.. What are the messaging models does EMS support?
a. Point-to-Point (Queue)
b. Publish and Subscribe (Topic)
c. Multicast (Topic)
3.What are the limitations of the Durable Subscriber?
• As long as the durable subscriber exists
• Expiration time of the message
• Storage limit of that Topic
4.What are the EMS Destination features?
• Secure Property
• Trace Property
• Store Property
• Redelivery policy
• Flow control
• Exclusive property for queues
5.What is structure of JMS Message?
• Header(Required)
• Properties(optional)
• Body(optional)
6.Where does the undelivered messages will be stored?
• 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
• You can only set the undelivered property on individual messages, there is no way to set the undelivered message queue as an option at the per-topic or per-queue level.
7.What are the messages bodies are supported by the EMS?
• Map Message
• Text Message
• Stream Message
• Bytes Message
• Object Message
8.What are the different delivery modes available in EMS?
• 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
• 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.
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
• Reliable
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.
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.
10.What is the purpose for stores.conf
• This file defines the locations either store files or a database, where the EMS server will store messages or metadata. Each store configured is either a file-based or a database store.
No comments:
Post a Comment