Avoid Multi-threading Using the JMSXUserID Property

3-6 Programming JMS for Oracle WebLogic Server

3.10 Alternative Qualities of Service, Multicast and No-Acknowledge

WebLogic JMS provides alternative qualities of service QOS extensions that can aid performance.

3.10.1 Using MULTICAST_NO_ACKNOWLEDGE

Non-durable topic subscribers can subscribe to messages using MULTICAST_NO_ ACKNOWLEDGE. If a topic has such subscribers, the JMS server will broadcast messages to them using multicast mode. Multicast improves performance considerably and provides linear scalability, as the network only needs to handle only one message, regardless of the number of subscribers, rather than one message per subscriber. Multicast messages may be lost if the network is congested, or if the client falls behind in processing them. Calls to recover or acknowledge have no effect on multicast messages. This QOS extension has the same level of guarantee as some JMS implementations default QOS from vendors other than Oracle WebLogic Server for non-durable topic subscriptions. The JMS 1.1 specification specifically allows non-durable topic messages to be dropped deleted if the subscriber is not ready for them. WebLogic JMS actually has a higher QOS for non-durable topic subscriptions by default than the JMS 1.1 specification requires.

3.10.2 Using NO_ACKNOWLEDGE

A no-acknowledge delivery mode implies that the server gives messages to consumers, but does not expect acknowledge to be called. Instead, the server pre-acknowledges the message. In this acknowledge mode, calls to recover will not work, as the message is already acknowledged. This mode saves the overhead of an additional network call to acknowledge, at the expense of possibly losing a message when a server failure, a network failure, or a client failure occurs. Asynchronous consumers that use a NO_ACKNOWLEDGE QOS may wish to tune down their message pipeline size in order to reduce the number of lost messages in the event of a crash.

3.11 Avoid Multi-threading

The JMS Specification, at http:java.sun.comproductsjmsdocs.html , states that multi-threading a session, producer, consumer, or message method results in undefined behavior except when calling close. For this release, if WebLogic JMS determines that you created a multi-threaded producer, the server instance throws a JMSException. If your application is thread limited, try increasing the number of producers and sessions. Note: On the client side, each multicasting session requires a dedicated thread to retrieve messages off the multicast socket. Therefore, you should increase the JMS client-side thread pool size to adjust for this. Note: If an asynchronous client calls close in this scenario, all messages in the asynchronous pipeline are lost. Best Practices for Application Design 3-7

3.12 Using the JMSXUserID Property

For WebLogic Server 9.0 and later, you can configure a JMS connection factory andor destination to automatically propagate the message senders authenticated username. The username is placed in a javax.jms.Message property named JMSXUserID. Consider the following points when using the JMSXUserID property in your application. ■ While the JMS specification makes some mention of JMSXUserID, the behavior is lightly defined and so will likely be different for different JMS vendors. ■ The JMSXUserID is based on the credential of the thread an application uses to create the JMS producer. It does not derive from the credential that is on a thread during the JMS send call itself. ■ JMS will ignore or override any attempt by an application to directly set JMSXUserID for example, javax.jms.Message.setXXXProperty will not work. ■ JMS messages are not signed or encrypted similar to any RMIEJB call. Therefore, fully secure transfers of the JMSXUserID require sending the message through secure protocols for example, t3s or https. ■ WebLogic Store-and-Forward agents do not propagate JMSXUserID they null it out. ■ WebLogic Messaging bridges will propagate JMSXUserID of the source destinations message if the messaging bridges are both are forwarding to a 9.0 or later JMS server and are configured to Preserve Message Properties. Otherwise, the forwarded message will either contain no username or the username used by the bridge sender. The latter behavior is determined by the configuration of the bridge senders connection factory and destination. ■ The WebLogic JMS WLMessageProducer.forward extension can forward a received messages JMSXUserID. For instructions on setting the JMSXUserID property on a connection factory or destination, see the following topics in the Administration Console online help: ■ Configure connection factory security parameters ■ Configure advanced queue parameters ■ Configure advanced topic parameters ■ Uniform distributed queues - configure advanced parameters ■ Uniform distributed topics - configure advanced parameters

3.13 Performance and Tuning