Question 1 :
How do I manage a queue to view and delete specific messages?
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?
The exception is usually something like java.io.InvalidClassException 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?
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?
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?
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.