Destination and Destination proeprties

Destination

Ø  Destinations for messages can be either Topics or Queues.

Ø  A destination can be created statically in the server configuration files, or dynamically by a client application.

Ø  Servers connected by routes exchange messages sent to temporary topics. As a result, temporary topics are ideal destinations for reply messages in request/reply interactions.

Ø  Difference between Static and Dynamic and Temporary queues/topics?

Static destinations will be created by using administrators configure.

Dynamic destinations client programs the flexibility to define destinations as needed for short-term use.

Temporary destinations are ideal for limited-scope uses, such as reply subjects.

Client programs will create.

Ø  What is the scope of delivery for Static and Dynamic and Temporary queues/topics?

Static destinations and Dynamic destinations support concurrent use.

i.e. several client processes can create local objects denoting the destination, and consume messages from it.

Temporary destinations support only local use i.e. only the client connection that created a temporary destination can consume messages from it.

Ø  However, servers connected by routes do exchange messages sent to temporary topics.

Ø  What is the duration for Static and Dynamic and Temporary queues/topics?

Static is permanent. A static destination remains in the server until an administrator explicitly deletes it.

Dynamic A dynamic destination remains in the server as long as at least one client actively uses it.

The server automatically deletes it when all applicable conditions are true:

• Topic or Queue all client programs that access the destination have disconnected

              • Topic no offline durable subscribers exist for the topic

              • Queue, no messages are stored in the queue

Temporary A temporary destination remains in the server either until the client that created it explicitly deletes it, or until the client disconnects from the server

Ø  Server-based bridges between destinations of the same or different types to create a hybrid messaging model for your application. This allows all messages delivered to one destination to also be delivered to the bridged destination.

You can bridge between different destination types, between the same destination types, or to more than one destination.

Ø  For example, you can create a bridge between a topic and a queue or from a topic to another topic.

Ø  Characters with Special Meaning in Destination Names

§  . Dot Separates elements within a destination name.

§  > Greater-than Wildcard character, matches one or more trailing

§  * Asterisk Wildcard character, matches one element

Destination properties

Ø  Properties for topics and queues can set directly in the topics.conf or queues.conf file or by means of the setprop topic or setprop queue command in the EMS Administration Tool.

Ø  channel property determines the multicast channel over which messages sent to this topic are broadcast. By including the channel property, the associated topic is enabled for multicast.

o   Only one channel is allowed for each topic. For this reason, overlapping wildcard topics are incompatible with channel properties.

Ø  exclusive property is available for queues only (not for topics), and cannot be used with global queues.

o   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 standby consumers as the new primary, and begins delivering messages to it.

o   expiration property is set for a destination, the server honors the overridden expiration period and retains the message for the length of time specified by the expiration property. However, the server overrides the JMSExpiration value set by the producer in the message header with the value 0 and therefore the consuming client does not expire the message.

o   When a message expires it is either destroyed or, if the JMS_TIBCO_PRESERVE_UNDELIVERED property on the message is set to true, the

o   message is placed on the undelivered queue so it can be handled by a special consumer

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

Ø  flowControl property specifies the target maximum size the server can use to store pending messages for the destination.

Ø  global property set are routed to the other servers that are participating in routing with this server.

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

Ø  maxbytes property is for setting size of Topics and queues to store, summed over all messages.

Ø  maxmsgs property 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

Ø  maxRedelivery property specifies the number of attempts the server should make to deliver a message sent to a queue.

Ø  overflowPolicy property to change the effect of exceeding the message capacity established by either maxbytes or maxmsgs.

Ø  default specifies that messages are sent to each subscriber in turn.

Ø  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.

Ø  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.

Ø  Prefetch

Ø  redeliveryDelay is set, the EMS server waits the specified interval before returning an unacknowledged message to the queue. When a previously delivered message did not receive a successful acknowledgement, the EMS server waits the specified redelivery delay before making the message available again in the queue

Ø  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.

Ø  sender_name property specifies that the server may include the sender’s username for messages sent to this destination.

Ø  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

Ø  store property determines where messages sent to this destination are stored. Messages may be stored in a file, or in a database.

Ø  trace property specifies that tracing should be enabled for this destination.

Ø  Temporary destinations, both topics and queues, support the following properties: • maxbytes • maxmsgs • overflowPolicy

Ø  Temporary destinations tend to be short-lived objects by nature. Applications have no control over destination names for temporary topics and queues. For

these reasons, you cannot directly set the above three supported properties on temporary destinations.

Ø  EMS defines a special temporary destination wildcard that can be used to assign properties and values to temporary topics and queues by way of inheritance.

— create topic $TMP$.> [properties]

— create queue $TMP$.> [properties]

— addprop topic $TMP$.> [properties]

— addprop queue $TMP$.> [properties]

— setprop topic $TMP$.> [properties]

— setprop queue $TMP$.> [properties]