Client-side Thread Pools Best Practices for JMS .NET Client Applications

14-26 Performance and Tuning for Oracle WebLogic Server ■ Uniform distributed queues - configure advanced parameters ■ Configure advanced JMS template parameters For more information about these parameters, see DestinationBean and TemplateBean in the Oracle WebLogic Server MBean Reference.

14.17.2 Compatibility With the Asynchronous Message Pipeline

The Message Performance Preference option is compatible with asynchronous consumers using the Asynchronous Message Pipeline, and is also compatible with synchronous consumers that use the Prefetch Mode for Synchronous Consumers feature, which simulates the Asynchronous Message Pipeline. However, if the value of the Maximum Messages value is set too low, it may negate the impact of the destinations higher-level performance algorithms e.g., Low, Medium, and High Waiting Threshold for Message Batching. For more information on the Asynchronous Message Pipeline, see Receiving Messages in Programming JMS for Oracle WebLogic Server.

14.18 Client-side Thread Pools

With most java client side applications, the default client thread pool size of 5 threads is sufficient. If, however, the application has a large number of asynchronous consumers, then it is often beneficial to allocate slightly more threads than asynchronous consumers. This allows more asynchronous consumers to run concurrently. WebLogic client thread pools are configured differently than WebLogic server thread-pools, and are not self tuning. WebLogic clients have a specific thread pool that is used for handling incoming requests from the server, such as JMS MessageListener invocations. This pool can be configured via the command-line property: -Dweblogic.ThreadPoolSize=n where n is the number of threads You can force a client-side thread dump to verify that this setting is taking effect.

14.19 Best Practices for JMS .NET Client Applications

The following is a short list of performance related best practices to use when creating a JMS .NET client application: ■ Always register a connection exception listener using an IConnection if the application needs to take action when an idle connection fails. ■ Have multiple .NET client threads share a single context to ensure that they use a single socket. ■ Cache and reuse frequently accessed JMS resources, such as contexts, connections, sessions, producers, destinations, and connection factories. Creating and closing these resources consumes significant CPU and network bandwidth. ■ Use DNS aliases or comma separated addresses for load balancing JMS .NET clients across multiple JMS .NET client host servers in a cluster. For more information on best practices and other programming considerations for JMS .NET client applications, see Programming Considerations in Use the WebLogic JMS Client for Microsoft .NET. 15 Tuning WebLogic JMS Store-and-Forward 15-1 15 Tuning WebLogic JMS Store-and-Forward For WebLogic Server releases 9.0 and higher, JMS provides advanced store-and-forward capability for high-performance message forwarding from a local server instance to a remote JMS destination. See Understanding the Store-and-Forward Service in Configuring and Managing Store-and-Forward for Oracle WebLogic Server. The following sections provide information on how to get the best performance from Store-and-Forward SAF applications: ■ Section 15.1, Best Practices