The following topics provide information on how to configure advanced message processing for inbound messages:
The JMS resource adapter uses a SHARABLE subscription sharing policy and UNRESTRICTED client ID policy when it processes inbound messages by overriding any configured connection factory settings. A subscriptionName must be provided for durable subscriptions because the JMS resource adapter's MDBs do not generate subscription names. Subscriptions are shared when they are durable or nondurable, as follows:
Durable—Consumers on the same distributed topic can share a durable subscriptions only if they have the same clientID, message selector, and subscriptionName.
Nondurable—Consumers on the same distributed topic can share a nondurable subscriptions only if they have the same clientID and messageSelector.
Always configure a clientId to ensure the MDB consumes incoming messages. For example:
. . .
<activation-config>
<activation-config-property>
<activation-config-property-name>clientId</activation-config-property-name>
<activation-config-property-value>myMDB</activation-config-property-value>
</activation-config-property>
</activation-config>
. . .
For more information, see Configure Shared Subscriptions in Administering JMS Resources for Oracle WebLogic Server.
If your application requires single-threaded processing of subscription messaging, then you must configure your application to use WebLogic JMS unit-of-ordering (UOO) processing.
For more information, see "Using Message Unit-of-Order" in Developing JMS Applications for Oracle WebLogic Server.
The following sections provide information on design strategies that can be used to develop high availability applications using distributed topics:
Replicated and partitioned distributed topics are supported for inbound message consumption as follows:
Replicated distributed topics—All physical topic members receive each message sent. When a message arrives at one of the physical topic members, a copy of the message is automatically and internally forwarded to the other members of the topic.
Partitioned distributed topics—The distributed topic member receiving the message is the only member that is aware of the message. The message is not forwarded to other members, and subscribers on other members do not get a copy of the message. Incoming messages can be load balanced among the distributed topic members using the JMS Affinity and Load Balance attributes. See Load Balancing Partitioned Distributed Topics in Administering JMS Resources for Oracle WebLogic Server.
One-Copy-Per-Application is the default design pattern available and has the following characteristics:
Each application as a whole (that is all instances of the application together) receives one copy of each message that is published to the distributed topic. That is each instance only receives a subset of the messages that are sent to the distributed topic.
An UNRESTRICTED client ID policy
An SHARABLE subscription sharing policy
Uses the same subscription name if the subscribers are durable
All consumers subscribe to the same topic instance (or member of a distributed topic)
To implement the One-Copy-Per-Application design strategy, you must specify the ProviderProperties property in your EJB with a value of TopicMessageDistributionMode=One-Copy-Per-Application in the activation-config element.
For more information, see Example One-Copy-Per-Application EJB Configuration.
Note:
If you do not specify TopicMessageDistributionMode=One-Copy-Per-Server, the JMS resource adapter defaults to TopicMessageDistributionMode=One-Copy-Per-Application to avoid message duplication.
The following code snippet from an ejb-jar.xml file implements One-Copy-Per-Application message processing:
. . .
<mdb-resource-adapter>
<resource-adapter-mid>wljmsra</resource-adapter-mid>
<activation-config>
<activation-config-property>
<activation-config-property-name>ClientId</activation-config-property-name>
<activation-config-property-value>RDT2MDB</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>ProviderProperties</activation-config-property-name>
<activation-config-property-value>TopicMessageDistributionMode=One-Copy-Per-Application</activation-config-property-value>
</activation-config-property>
</activation-config>
</mdb-resource-adapter>
<!-- Mapping a Queue admin-object to the Resource-Adapter name -->
<resource-env-ref>
<resource-env-ref-name>jms/ResultTopic</resource-env-ref-name>
<jndi-name>wljmsra/rtopic1</jndi-name>
</resource-env-ref>
<!-- Mapping a Connection Factory to the Resource-Adapter name -->
<resource-ref>
<res-ref-name>jms/ResultXACFFactory</res-ref-name>
<jndi-name>wljmsra/xacf</jndi-name>
</resource-ref>
. . .
One-Copy-Per-Server is a design pattern where each instance of an application gets one copy of each message that is published to the topic.
To implement the One-Copy-Per-Server design strategy, you must:
Specify the weblogic.jms.ra.providers.wl.ServerID property when starting the foreign server instance. For example: -Dweblogic.jms.ra.providers.wl.ServerID=aUniqueIdForTheServer
In the preceding property specification, aUniqueIdForTheServer represents a unique identifier for your foreign server.
For Oracle Glassfish, you can configure this property using the asadmin command, as follows:
asadmin> create-jvm-options --user myUsername --password myPassword --host localhost --port 4848 -Dweblogic.jms.ra.providers.wl.ServerID="aUniqueIdForTheServer"
Specify the ProviderProperties property in your EJB with a value of TopicMessageDistributionMode=One-Copy-Per-Server in the activation-config element. For more information, see Example One-Copy-Per-Application EJB Configuration.
The following code snippet from an ejb-jar.xml file implements One-Copy-Per-Server message processing:
. . .
<mdb-resource-adapter>
<resource-adapter-mid>wljmsra</resource-adapter-mid>
<activation-config>
<activation-config-property>
<activation-config-property-name>ClientId</activation-config-property-name>
<activation-config-property-value>RDTMDB</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>ProviderProperties</activation-config-property-name>
<activation-config-property-value>TopicMessageDistributionMode=One-Copy-Per-Server</activation-config-property-value>
</activation-config-property>
</activation-config>
</mdb-resource-adapter>
<!-- Mapping a Queue admin-object to the Resource-Adapter name -->
<resource-env-ref>
<resource-env-ref-name>jms/ResultTopic</resource-env-ref-name>
<jndi-name>wljmsra/rtopic1</jndi-name>
</resource-env-ref>
<!-- Mapping a Connection Factory to the Resource-Adapter name -->
<resource-ref>
<res-ref-name>jms/ResultXACFFactory</res-ref-name>
<jndi-name>wljmsra/xacf</jndi-name>
</resource-ref>
. . .
On each foreign application server instance that hosts the MDB application, an MDB pool is created for the topic, whether the topic is running in the same cluster or in a different cluster. For an MDB cluster of N nodes, N MDB pools are created. Each MDB pool creates an individual subscription on the topic, and subscribers from different MDB pools do not share the same subscription.
For more information, see Implementing One-Copy-Per-Server.