Using Distributed Destinations 9-5
distributed topic represents multiple physical topics is mostly transparent to the application.
The topic members can be located anywhere but must all be served either by a single WebLogic Server or any number of servers in a cluster. When a message is sent to a
distributed topic, it is sent to all of the topic members in the distributed topic set. This allows all subscribers to the distributed topic to receive messages published for the
distributed topic.
A message published directly to a topic member of a distributed destination that is, the publisher did not specify the distributed destination is also forwarded to all the
members of that distributed topic. This includes subscribers that originally subscribed to the distributed topic, and which happened to be assigned to that particular topic
member. In other words, publishing a message to a specific distributed topic member automatically forwards it to all the other distributed topic members, just as publishing
a message to a distributed topic automatically forwards it to all of its distributed topic members. For more information about looking up specific distributed destination
members, see
Section 9.5.4, Accessing Distributed Destination Members. This section provides information on using distributed topics:
■
Section 9.5.2.1, TopicPublishers
■
Section 9.5.2.2, TopicSubscribers
■
Section 9.5.2.3, Deploying Message-Driven Beans on a Distributed Topic
9.5.2.1 TopicPublishers
When creating a topic publisher, if the supplied destination is a distributed destination, then any messages sent to that distributed destination are sent to all
available topic members for that distributed topic, as follows:
■
If one or more of the distributed topic members is not reachable, and the message being sent is non-persistent, then the message is sent only to the available topic
members.
■
If one or more of the distributed topic members is not reachable, and the message being sent is persistent, then the message is stored and forwarded to the other
topic members when they become reachable. However, the message can only be persistently stored if the topic member has a JMS store configured.
Note: Durable subscribers DurableTopicSubscriber cannot be
created for distributed topics. However, you can still create a durable subscription on distributed topic member and the other topic
members will forward the messages to the topic member that has the durable subscription.
Note:
Every effort is made to first forward the message to distributed members that utilize a persistent store. However, if none
of the distributed members utilize a store, then the message is still sent to one of the members according to the selected load-balancing
algorithm, as described in Configuring Distributed Destination Resources in Configuring and Managing JMS for Oracle WebLogic Server.
9-6 Programming JMS for Oracle WebLogic Server
■
If all of the distributed topic members are unreachable regardless of whether the message is persistent or non-persistent, then the publisher receives a
JMSException when it tries to send a message.
9.5.2.2 TopicSubscribers
When creating a topic subscriber, if the supplied topic is a distributed topic, then the topic subscriber receives messages published to that distributed topic. If one or more
of the topic members for the distributed topic are not reachable by a topic subscriber, then depending on whether the messages are persistent or non-persistent the
following occurs:
■
Any persistent messages published to one or more unreachable distributed topic members are eventually received by topic subscribers of those topic members once
they become reachable. However, the messages can only be persistently stored if the topic member has a JMS store configured.
■
Any non-persistent messages published to those unreachable distributed topic members will not be received by that topic subscriber.
Ultimately, a topic subscriber is pinned to a physical topic member. If that topic member becomes unavailable, then the topic subscriber will receive a JMSException,
as follows:
■
If the topic subscriber is synchronous, then the exception is returned to the user directly.
■
If the topic subscriber is asynchronous, then the exception is delivered inside of a ConsumerClosedException that is delivered to the ExceptionListener
defined for the consumer session, if any.
Upon receiving such an exception, an application can close its topic subscriber and recreate it. If any other topic member is available within the distributed topic, then the
creation should be successful and the new topic subscriber will be pinned to one of those topic members. If no other topic member is available, then the application will
not be able to recreate the topic subscriber and will have to try again later.
Note: If a JMS store is configured for a JMS server that is hosting a
distributed topic member, then all the Distributed Topic System Subscribers associated with that member destination are treated as
durable subscriptions, even when a topic member does not have a JMS store explicitly configured. As such, the saving of all the
messages sent to these distributed topic subscribers in memory can result in unexpected memory and disk consumption. Therefore, a
recommended best design practice when deploying distributed destination is to consistently configure all member destinations: either
with a JMS store for durable messages, or without a JMS store for non-durable messages. For example, if you want all of your
distributed topic subscribers to be non-durable, but some member destinations implicitly have a JMS store configured because their
associated JMS server uses a JMS store, then you need to explicitly set the StoreEnabled attribute to False for each member destination to
override the JMS server setting.
Using Distributed Destinations 9-7
9.5.2.3 Deploying Message-Driven Beans on a Distributed Topic
