Set - 3

Question 1 :

How do I manage a queue to view and delete specific messages?

Answer :

Write a program that uses a QueueBrowser. Then delete specific messages by using a selector with the message identifier as in the following example:

String selector = "JMSMessageID = '" + message.getMessageID() + "'";
Keep in mind that the queue browser is a not a "live" view of the queue. It is a snap-shot.

Question 2 :

Why do I get an exception when trying to find a connection factory?

Answer :

The exception is usually something like or java.lang.NoClassDefFoundError.
Make sure weblogic.jar is in the CLASSPATH of the client. Also make sure you have the correct Java run-time jar files included (i.e., you might need rt.jar).

Question 3 :

What precautions should I take when I use blocking receive() calls?

Answer :

If your application design requires messages to be received synchronously, we recommend using one of the following methods listed in order of preference:
* Pass a timeout value as an argument to the receive() method and set it to the minimum value greater than zero, that is allowed by the application to avoid consuming threads that are waiting for a response from the server.
* Use the receiveNoWait() method which returns the next message or a null value if no message is currently available. In this case, the call does not block. The servlet should provide a way to return to or reschedule the request, without calling wait().
Note: Use of this option should be minimized, as it may deadlock a busy server.
* Ensure that more threads are configured than the number of possible simultaneous blocking receive() calls.

Question 4 :

What is the NO_ACKNOWLEDGE acknowledge mode used for?

Answer :

The NO_ACKNOWLEDGE acknowledge mode indicates that received messages do not need to be specifically acknowledged which improves performance, but risks that messages are lost. This mode is supported for applications that do not require the quality of service provided by session acknowledge and that do not want to incur the associated overhead. v Messages sent to a NO_ACKNOWLEDGE session are immediately deleted from the server. Messages received in this mode are not recovered and, as a result, messages may be lost and/or duplicate message may be delivered if an initial attempt to deliver a message fails.
Note: You should avoid using this mode if your application cannot handle lost or duplicate messages. Duplicate messages may be sent if an initial attempt to deliver a message fails.
In addition, we do not recommend that this acknowledge mode be used with persistent messaging, as it implies a quality of service that may be too low for persistent messaging to be useful.

Question 5 :

When should I use multicast subscribers?

Answer :

Multicasting enables the delivery of messages to a select group of hosts that subsequently forwards the messages to multicast subscribers. The benefits of multicasting include:

* Near real-time delivery of messages to host group.
* High scalability due to the reduction in the amount of resources required by the JMS server to deliver messages to multicast subscribers.

Note: Multicasting is only supported for the Pub/sub messaging model.

For an example of when multicasting might be useful, consider a stock ticker. When accessing stock quotes, timely delivery is more important than reliability. When accessing the stock information in real-time, if all, or a portion, of the contents is not delivered, the client can simply request the information be resent. Clients would not want to have the information recovered in this case because by the time it is redelivered it would be out-of-date.
Multicast messages are not guaranteed to be delivered to all members of the host group. For messages requiring reliable delivery and recovery, you should not use multicasting.

Question 6 :

When should I use server session pools and connection consumers?

Answer :

WebLogic JMS implements an optional JMS facility for defining a server-managed pool of server sessions. This facility enables an application to process messages concurrently. A ConnectionConsumer object uses a server session to process received messages. If message traffic is heavy, the connection consumer can load each server session with multiple messages to minimize thread context switching. Multiple connection consumers can share server sessions in a server session pool.
To learn how to use the connection consumers within an application, see the section Processing Messages Concurrently in Programming WebLogic JMS, or the javax.jms.ConnectionConsumer javadoc.
Note: Server session pools can also be implemented using Message Driven Beans. Using MDBs is preferable to using server session pools - see the answer to the question, "How do server session pools and Message Driven Beans compare?" For information on using message driven beans to implement server session pools, see Programming WebLogic Enterprise JavaBeans.

Question 7 :

How do I issue the close() method within an onMessage() method call and what are the semantics of the close() method?

Answer :

If you wish to issue the close() method within an onMessage() method call, the system administrator must select the Allow Close In OnMessage check box when configuring the connection factory. For more information, see JMS Connection Factories in the Administration Console Online Help. If this check box is not selected and you issue the close() method within an onMessage() method call, the call will hang.

The close() method performs the following steps to execute an orderly shutdown:
* Terminates the receipt of all pending messages. Applications may return a message or null if a message was not available at the time of the close.
* Waits until all message listeners that are currently processing messages have completed (except for the message listener from which the close() method is being called).
* Rolls back in-process transactions on its transacted sessions (unless such transactions are part of an external JTA user transaction).
* Does not force an acknowledge of client-acknowledged sessions. By not forcing an acknowledge, no messages are lost for queues and durable subscriptions that require reliable processing.

When you close a connection, all associated objects are also closed. You can continue to use the message objects created or received via the connection, except the received message's acknowledge() method. Closing a closed connection has no effect.
Note: Attempting to acknowledge a received message from a closed connection's session throws an IllegalStateException.
When you close a session, all associated producers and consumers are also closed.
For more information about the impact of the close() method for each object, see the appropriate javax.jms javadoc.

Question 8 :

How do I publish an XML message?

Answer :

Follow these steps:
1. Generate XML from the DOM document tree.
2. Serialize the generated DOM document to a StringWriter.
3. Call toString on the StringWriter and pass it into message.setText.
4. Publish the message.

Question 9 :

Is it possible to send or receive a message from within a message listener?

Answer :

Yes. You can send to or receive from any queue or topic from within in a message listener.
If it's not an MDB, you can use the same Connection or Session that the onMessage() is part of to do this. When you create your message listener, you pass in a session in your constructor. Then you have access to the session in your onMessage method and you would be able to make synchronous, not asynchronous, calls from within the onMessage method. Do not use another Session that is servicing another onMessage() because that would multi-thread that Session and Sessions don't support multi-threading.
When things are done non-transactionally, there can be duplicates or lost messages (assuming your onMessage() code is attempting to forward messages):
1. If you call acknowledge after the publish() and the acknowledge fails for whatever reason (network/server failure), then you will see the message again and will end up publishing twice (possible duplicate semantics). You can try to keep track of sequence numbers to detect duplicates but this is not easy.
2. If you call acknowledge before the publish(), you get at-most-once semantics. If the publish() fails, you don't know if the failure occurred before or after the message reached the server.
If you want exactly once, transactional semantics using onMessage, you must use transactional MDBs. The onMessage() for a transactional MDB starts the transaction, includes the WebLogic Server JMS message received within that transaction and the publish() would also be in the same transaction. The following code sends a response to each message that it receives. It creates the connection, etc. in the ejbCreate method so that it doesn't need to create it every time onMessage is called. The QueueSender is anonymous (null Queue) since we don't know to whom we will have to reply. The ejbRemove method cleans up by closing the connection. This same approach can be used to create a receiver, subscriber or publisher.
import javax.ejb.CreateException;
import javax.ejb.EJBContext;
import javax.naming.*;
import java.util.Hashtable;
import javax.ejb.MessageDrivenBean;
import javax.ejb.MessageDrivenContext;
import javax.jms.*;

public class MDB
implements MessageDrivenBean, MessageListener {
public static final String WLSqcf =
public static final String WLSqname =
public static final String WLSurl =
public static final String WLSJNDIfactory =
private MessageDrivenContext context;
private QueueSession session;
private QueueConnection connection = null;
private QueueConnectionFactory factory;
private InitialContext ctx;
private QueueSender QueueSender;

// Required - public constructor with no argument
public MDB() {}

// Required - ejbActivate
public void ejbActivate() {}
// Required - ejbRemove
public void ejbRemove() {
context = null;
if (connection != null) {
try {
} catch(Exception e) {}
connection = null;

// Required - ejbPassivate
public void ejbPassivate() {}

public void setMessageDrivenContext(
MessageDrivenContext mycontext) {
context = mycontext;

// Required - ejbCreate() with no arguments
public void ejbCreate () throws CreateException {
try {
// Get the initial context
Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, WLSurl);
env.put(Context.REFERRAL, "throw");
ctx = new InitialContext(env);

factory = (QueueConnectionFactory)ctx.lookup(WLSqcf);

// Create a QueueConnection, QueueSession, QueueSender
connection = factory.createQueueConnection();
session = connection.createQueueSession(false,
queueSender = session.createSender(null);
} catch (Exception e) {
throw(new CreateException(e.toString()));

// Implementation of MessageListener
// Throws no exceptions
public void onMessage(Message msg) {
try {
System.out.println("MDB: " +
((TextMessage)msg).setText("reply message");
queueSender.send((Queue)msg.getJMSReplyTo(), msg);
catch(Exception e) { // Catch any exception


This approach creates a connection per EJB/MDB instance, so you might want to create a producer pool that is shared by the EJB instances. This is done by writing a class that populates a static pool with producers (see the next question for a sample producer pool). The onMessage call grabs a producer when needed. Since Sessions must be single threaded, make sure there is only one producer per session within the producer pool.

Question 10 :

How do I create a producer pool?

Answer :

The following is some pseudo-code
for a producer class.

class ProducerPool {
static Hashmap pSets = new Hashtable();
static Hashmap inUse = new Hashtable();

QueueSender get(String contextURL,
String connectionFactoryName,
String destinationName) {
String lookup = contextURL+";
synchronized(pSets) {
producer set = pSets.get(lookup);
if (set != null && set not empty)
qs = set.removeFirst();
if (producer == null) {
create ctx
get connect factory
create connection
create session
look up destination
qs = create queue sender
synchronized(inUse) {
inUse.put(qs, lookup);
return qs;

void put(QueueSender qs) {
String lookup;
synchronized(inUse) {
lookup = inUse.remove(p);
synchronzied(pSets) {
producer set = pSets.get(lookup);
if (set == null) {
producer set = new producer set
pSets.put(lookup, producer set);
producer set.add(qs);

Note: Static classes may be garbage collected if there are no references to them, so make sure the application server has a permanent pointer to them in some manner. One way is to reference it permanently from within a servlet or EJB when they are initialized at startup.
Here is an example of using the producer pool within the onMessage method.
onMessage() {
QueueSender qs = ProducerPool.get(...);

You can pre-populate this pool by calling it from a startup class or a load-on-start servlet class.

Question 11 :

What are pending messages in the console?

Answer :

Pending means the message could have been:
* sent in a transaction but not committed.
* received and not acknowledged.
* received and not committed.
* subject to a redelivery delay (as of WebLogic Server 6.1).
* subject to a delivery time (as of WebLogic Server 6.1).
A rolled back message remains pending until the transaction actually rolls back. Rolling it back multiple times does not cause double counting, nor does an exception that set a transaction as rollbackOnly followed by an actual rollback.
Current implies messages that are not pending.
Total implies total since server last started. The byte counts only consider the payload of messages which includes the properties and the body but not the header.

Question 12 :

How do I use a less than or greater than on a message selector in ejb-jar.xml?

Answer :

Enclose the selector in a CDATA section. That will prevent the XML parser from thinking that less than or greater than is a tag.

'user' ]]>

Question 13 :

Is it better to have more or fewer sessions for a given number of subscribers?

Answer :

Using N sessions for N subscribers gives you concurrency up to N simultaneous threads of execution provided you have as many threads to work with. Each Session gets its own thread as long as there are enough threads available. Otherwise, the sessions serially reuse the available threads.
One session for N subscribers serializes all subscribers through that one session. If the load is heavy they may not be able to keep up without the extra threads.
If you are using CLIENT_ACKNOWLEDGE, N sessions gives you N separate message streams that can be individually recovered. Having one session crosses the streams giving you less control.

Question 14 :

Are foreign destinations handled within foreign JMS messages?

Answer :

WebLogic Server JMS does not know what to do with foreign destinations that it runs into. This issue has been discussed with Sun and the JMS specification does not clearly define destinations well enough for vendors to interoperate at that level. They agree that it is sufficient not to handle foreign destinations preferably in such a way that sending/receiving still work. For WebLogic Server JMS, if you do a setJMSdestination (you should not because it is only for the provider to set it) with a foreign destination, it gets ignored (set to null). Similarly, if you do a setJMSReplyTo for a foreign destination, WebLogic Server JMS will ignore it (set it to null).

Question 15 :

What is the standard way to create threads, do initialization, etc. within the application server?

Answer :

Threads should generally not be created by the user directly is because things may not work correctly. User-created threads do not have some of the thread-local variables pre-set by WebLogic when it creates it's own execute threads, the associated transaction context, or the environment such as the proper class loader. The WebLogic-specific way of doing this is with a startup class or using the WebLogic Time Services. The portable way to do this is to define a load-on-startup servlet, doing the initialization in the init() method and the cleanup in the destroy() method. The servlet itself does nothing. This approach also allows for undeploy/redeploy of the application without restarting the server, including proper cleanup/initialization each time. It also providers more dynamic management of the dependent classes without restarting the server.

Question 16 :

How many messages are sent across the network for processing topic messages? If there are three subscribers for a message, for example, one of which with a selector that does not match, how many messages are sent?

Answer :

In WebLogic JMS 6.1, when all three consumers are in the same session, we send one copy of the message across the network for all subscribers that are not flow-controlled. Once a consumer is flow-controlled for not acknowledging enough messages, no messages are sent until flow control is eased. So, the answer is usually one, but may be two. The selection is done on the server side so a subscriber that doesn't match doesn't have to discard anything.

Question 17 :

What should an XPATH selector look like?

Answer :

The following is an example of an XPATH selector. Pay careful attention to the use of double and single quotes.

String selector =
"JMS_BEA_SELECT('xpath', '/recipient/transport/text()') =
tsubscriber = tsession.createSubscriber(topic, selector, false);

JMS_BEA_SELECT is a built-in function in WebLogic Server JMS SQL syntax. You put it in your selector string when you create a consumer. Note the use of single quotes around xpath, the XML tab, and the string value.

Question 18 :

How do I handle request/response using JMS?

Answer :

There are several approaches to handling request/response processing with JMS.
* Use a temporary queue for each requestor and have the response go back to that queue.
* Use the QueueRequestor class, which does the temporary queue for you, and wait for the reply, as in the following:
// create temporary queue for receiving answer
qrequestor = new QueueRequestor(qsession, queue);
TextMessage msg = qsession.createTextMessage();
TextMessage reply = (TextMessage) qrequestor.request(msg);
* Use a dedicated response topic or queue with message selectors.

Question 19 :

How do I put a message back on the queue for processing?

Answer :

The following are several approaches:
* Use a transacted session, then rollback the session so the message will go back to the queue.
* Use Session.CLIENT_ACKNOWLEDGE when creating a session, then recover the session so the message will go back to the queue.
* Use a JTA transaction, then rollback the transaction so the message will go back to the queue.

Question 20 :

Is it OK to add new sessions and subscribers to a Queue or Topic Connection once it has been started?

Answer :

Yes, with one caveat. You may not add new subscribers/consumers to a session if it already has active async consumers. Sessions must only be accessed single-threaded as per the JMS spec. If you feel you need to do this, create a new Session and add it to that one instead.
You can add receivers to a started connection. A receiver in itself is not asynchronous. You need a listener to make it asynchronous. The first creation of a receiver is always safe. If you then add a listener for that first receiver, you have to worry for any future receivers in that same session. You can create new sessions and the first receiver for that session with no worries.
Once you want to create a second receiver in a session, if the first receiver has a MessageListener, you have to take care to make sure there are no other threads of execution in that session. You can do this by stopping the connection or actually creating your receiver from the onMessage routine of the first receiver.

Question 21 :

What can I do when I get java.lang.OutOfMemoryError because producers are faster than consumers?

Answer :

Quotas can be used to help this situation. Your sender will then receive ResourceAllocationExceptions and the server will stay up. WLS 6.X does not support paging of messages out of memory.
As of WLS 6.1 SP02 or later, you can use the Message Paging feature, which can free up valuable virtual memory during peak message load periods by swapping out messages from virtual memory to persistent storage when message loads reach a specified threshold.

Question 22 :

How do I debug WebLogic Server using Visual Cafe 4.1?

Answer :

You can install VisualCafe Enterprise Edition 4.1 and attach it to the server, pretty much as it worked for 3.X.
The following are steps for debugging using VC 4.1. You may change the directory names as necessary.
1. Install it under D:\VisualCafeEE. No special options are needed.
2. Install the license under C:\Program Files\Common Files\WebGain Shared.
3. Start ddservices by selecting Start -> Programs -> WebGain Studio Professional ->Visual Cafe Enterprise Edition 4.1 -> Distributed Debugging Services -> Start DD Services (Java2 - 1.3)
4. Start WebLogic Server using debugvm.exe instead of java.exe.
cd D:\bea\wlserver6.1\config\mydomain
edit startWebLogic.cmd
change "%JAVA_home%\bin\java" -hotspot -ms64m -mx64m to \visualcafeEE\jdk13\bin\debugvm.exe
5. Run startWebLogic. It prints out some debugging information.
6. Run VisualCafe - Start -> Programs -> WebGain Studio Professional -> Visual Cafe Enterprise Edition 4.1 -> Visual Cafe Enterprise Edition 4.1
7. From the File menu, select Attach to Process. If everything is working correctly, you should see your machine name.
8. Click the + sign to expand the tree and select your running WebLogic Server.

Question 23 :

How can I avoid asynchronous message deadlocks?

Answer :

Due to a limitation in the JMS 1.0.2 specification, asynchronous messages can become deadlocked if the close() method of a session is inside a user-synchronized block. To resolve this, you must move the close() method outside the user-synchronized block. For example:
public class CloseTest() {
private void xxx() {
synchronized (this) {
create connection/session/consumer
initialize and set a listener for this consumer;

private void onMessage(Message message) {
synchronized (this) {

Before the connection.close() method is closed, another message can be delivered to the onMessage routine by the JMSProvider. The main() method thread owns the monitor lock for the CloseTest method. Before the onMessage() method of the CloseTest class fires, JMS sets INLISTENER as the state for the session in JMSSession (the JMS specification says that the close() method must wait for the onMessage routine), so that the main() method thread can wait for the onMessage routine to complete.
Now when the onMessage routine tries to acquire the monitor lock, it blocks waiting for the main() method thread to give up, and the main() method thread is waiting for the onMessage to be completed.
JMS also blocks when the close() method of a consumer is done from an onMessage routine and the allowCloseInOnMessage attribute is set to false in the config.xml file.

Question 24 :

How does concurrency work for message-driven beans?

Answer :

The way concurrency is achieved for Queues is by spawning one JMSSession per MDB instance in the pool. Since JMSSessions are processed in parallel by JMS, concurrency is obtained naturally this way and JMS takes care of delivering the message to, at most, one listener. If an MDB is deployed to multiple servers in a cluster, JMSSessions are created for each MDB instance on each server and load balancing will be done across them.
For Topics in WebLogic JMS 6.1, there is one JMSSession per bean instance in the pool. Because of the way Topics work, the session, and thus every bean instance, receives a copy of each message published on that Topic. (There was also a problem that caused parallel processing not to work correctly. This has been fixed for WLS 6.0 Service Pack 1.) Within a single server, one topic consumer is used to pass out messages to multiple threads to get the concurrency while producing only a single copy of each message. You can configure multiple MDBs to listen on the same topic and each MDB will receive a copy of every message. When using multiple servers, each server gets its own consumer and therefore its own copy of each message. It is not currently possible to share a consumer across multiple servers. If you want a message to be processed by exactly one MDB, use a queue.
One customer had an example where topic MDBs are needed in which there will be multiple implementations of the MDBs listening on the same topic. In other words, more than one MDB with a different implementation may be subscribing to the same topic. The client has no advanced way of knowing how many different kinds of MDBs may be listening on the same topic, but it is possible for there to be more than one listener, therefore topics, not queues. For each kind of MDB listening on the topic, the message is delivered exactly once (i.e., the message will be delivered exactly once to an instance in each named MDB pool listening on the topic).

Question 25 :

Can an MDB be a message producer or both a producer and consumer?

Answer :

Yes. You have no JMS context inside the MDB so you will need to establish a connection, session and producer yourself. One option is to do this every time you come into the onMessage routine for the MDB. This is sufficient if the message rate is relatively low. The second option is to establish the necessary objects in ejbActivate(). Note that the objects are not serializable so they can't be passivated for a stateful session bean or an entity bean. When the EJB deactivates, you need to close the associated objects. The third option is that you could build up a JMS connection/sender session pool within a startup class complete with your own synchronization and blocking to get a connection. There is an example in the answer to the question "Is it possible to send or receive a message from within a message listener?"

Question 26 :

Can you use a foreign JMS provider to drive an MDB transactionally?

Answer :

No. The message is asynchronously received outside a transaction and there is no J2EE API to then associate the message with a transaction.
The only reason this works for WebLogic Server JMS is that we have defined a WebLogic Server extension interface that has a method to associate a message with a transaction. This interface, MDBTransaction, is defined in news://$ It has one method, associateTransaction(), that takes a javax.jms.Message parameter. This message must be associated with the transaction. We are hoping that other JMS vendors interested in integrating with WebLogic Server will implement this interface.
Another approach called source managed transactions, would be for there to be an API to tell the JMS provider to start a transaction on your behalf before delivering the message to an asynchronous consumer. This API doesn't exist in J2EE either. Even if there were such a provision, few non-WLS JMS providers can begin and drive such a transaction by themselves.
The current solution is to move all messages from the foreign destination to a WebLogic Server JMS destination (within a transaction if the foreign JMS provider supports it) and have that WebLogic Server JMS destination drive the MDB transactionally (using the WLS JMS special interface). Currently, the messages can be moved between providers using code similar to that described in the "Using Foreign JMS Providers With WebLogic Server" white paper. This code could be contained in a startup class that starts a thread and does the following:
while (true) {
start a transaction
receive a message synchronously with timeout
if timed_out { rollback and continue }
do the work
commit the transaction }

Doing a synchronous receive will have a problem in that the transaction may time out before the message is received. You can do the receive with a specified timeout, allowing enough time left in the transaction to complete the work. If the receive fails, roll back the transaction and try again. It is also not as efficient as MDBs since it does a synchronous instead of asynchronous receive (it ties up threads). Also, if you get a lot of timeouts, you will be burning more CPU.
Eventually, WLS JMS will provide a bridge to handle this message passing out-of-the box.
With any of these approaches, the XAResource must be registered with the Transaction Manager (this is done automatically for WebLogic Server JMS).

Question 27 :

How do I use JTA transactions within an MDB?

Answer :

In the ejb-jar.xml file, define the transaction type as Container and the trans-attribute as Required, as in the following example:





To rollback a transaction, you can either use the WebLogic extension TXHelper or you can use the MDB context as in the following code examples:
UserTransaction ut =

private MessageDrivenContext context;
public void setMessageDrivenContext(
MessageDrivenContext mycontext) {
context = mycontext;
public void onMessage(Message msg) {
try { // some logic
catch(Exception e) {
System.out.println("MDB doing rollback");

Question 28 :

Why did the messaging bridge fail to connect to the source bridge destination?

Answer :

Either an error occurred when configuring the source bridge destination parameters, or the actual source destination is not running and cannot communicate with the messaging bridge.

* Verify whether the bridge's source destination is correctly configured, by making sure that the following fields on the JMS Bridge Destination —> Configuration —> General console page have been properly completed:

o Connection URL—this must be the URL of the JNDI provider used to look up the connection factory and actual destination.
o Destination JNDI Name—this must be the JNDI name of the actual destination mapped to the source bridge destination.
o Connection Factory JNDI Name—this must be the connection factory used to create a connection for the actual destination mapped to the source bridge destination.
o User Name/Password—make sure that this user ID has permission to access the actual source destination.
* Verify that the actual source queue or topic destination mapped to the source bridge destination is running and healthy, as follows:
o Is the WebLogic Server instance hosting the source destination running?
o Is the JMS server hosting the source destination correctly deployed?

Note: This troubleshooting scenario for correcting a source bridge destination connection failure also applies to target bridge destinations.

Question 29 :

Can the messaging bridge handle two-phase or global transactions between separate WebLogic Server domains or between different releases?

Answer :

Yes, as long as the communication is between source and target WebLogic domains that are both running release 6.1 SP3 or later, and the bridge is configured to use the Exactly-once quality of service.
I configured the messaging bridge to use the Exactly-once quality of service for two-phase transactions. So why am I getting a "quality of service is unreachable" error?
There are some additional configuration requirements for the messaging bridge to handle transactions between WebLogic domains:

* The supported adapters are located in the WL_home\lib directory. For the Exactly-once QOS, the transaction adapter, jms-xa-adp.rar, must be deployed in the release 6.1 domain where the bridge is running, via the select Deployments —> Applications node on the console.
* This jms-xa-adp.rar adapter must also be identified in the Adapter JNDI Name attribute as eis.jms.WLSConnectionFactoryJNDIXA on the JMS Bridge Destination —> Configuration tab for both the source and target bridge destinations.
* For WebLogic JMS, verify that you are using the transactional XAConnectionFactory for the queue or topic destinations mapped to both the source and target bridge destinations. To verify this, the following attributes must be set on the JMS —> Connection Factory —> Configuration —> Transactions console tab or in the configuration file (config.xml):
* For third-party JMS vendors, verify that you are using a transactional connection factory for the destinations mapped to the source and target bridge destinations.

Question 30 :

Can I configure the messaging bridge to automatically downgrade the quality of service if the Exactly-once service isn't available on either the source or target bridge destination?

Answer :

Yes, just make sure to select the QOS Degradation Allowed check box on the Messaging Bridge —> Configuration —> General administration console page.