Wildcards in Topics,Queues and multicast

-

Wildcards in Topics
Ø  You can subscribe to wildcard topics.
§  If you subscribe to a topic containing a wildcard, you will receive any message published to a matching topic
Ø  You cannot publish to wildcard topics
§  If foo.bar is not in the configuration file, then you can publish to foo.bar if foo.* or foo.> exists in the configuration file.
Wildcards in Queues
Ø  You can neither send to nor receive from wildcard queue names. However, you can use wildcard queue names in the configuration files.
§  For example, if the queue configuration file includes a line: foo.* then users can dynamically create queues foo.bar, foo.bob, and so forth, but not foo.bar.bob.
Wildcards and Multicast
Ø  Messages published to multicast-enabled topics are sent on the multicast channels defined for those topics. A wildcard may cover multiple multicast-enabled topics, each on a different multicast channel.
Wildcards and Dynamically Created Destinations
Ø  The EMS server may dynamically create destinations on behalf of its clients. The use of wildcards in the .conf files can be used to control the allowable names of dynamically created destinations.
Ø  The same basic wildcard rules apply to dynamically created destinations as described above for static destinations
• If the queues.conf file contains: >
              The EMS server can dynamically create a queue with any name.
• If the topics.conf file contains only: foo.>
              The EMS server can dynamically create topics with names like foo.bar,
              foo.boo, foo.boo.bar, and foo.bar.boo.
• If the queues.conf file contains only: foo.*
  The EMS server can dynamically create queues with names like foo.bar    and foo.boo, but not foo.bar.boo.

Inheritance
Ø  All destination properties are inheritable for both topics and queues. This means that a property set for a "wildcarded" destination is inherited by all destinations with matching names.
§  For example, if you have the following in your topics.conf file: foo.* secure then Topics foo.bar and foo.bob are secure topics because they inherit secure from their parent, foo.*. If your EMS server were to dynamically create a foo.new topic, it too would have the secure property.
Ø  The properties inherited from a parent are in addition to the properties defined for the child destination.
§  For example, if you have the following in your topics.conf
  file:foo.* secure
  foo.bar sender_name
§  Then foo.bar has both the secure and sender_name properties.
Ø  Properties that are assigned values, you can override the value established in a parent.
§  For example, if you have the following in your queues.conf
·          foo.* maxbytes=200
·         foo.bar maxbytes=2000
§  The foo.bar queue has a maxbytes value of 2000.
Ø  When there are multiple ancestors for a destination, the destination inherits theproperties from all of the parents.
§  For example:
·         > sender_name
·         foo.* secure
·          foo.bar trace
§  The foo.bar topic has the sender_name, secure and trace properties.
Ø  When there are multiple parents for a destination that contain conflicting property values, the destination inherits the smallest value.
§  For example:
·          > maxbytes=2000
·         foo.* maxbytes=200
·          foo.bar
§  The foo.bar topic has a maxbytes value of 200.

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