9 Tuning Message-Driven Beans

Use the tuning and best practice information of Oracle WebLogic Server for Message-Driven Beans (MDBs).

• Use Transaction Batching

• MDB Thread Management

• Best Practices for Configuring and Deploying MDBs Using Distributed Topics

• Using MDBs with Foreign Destinations

• Token-based Message Polling for Transactional MDBs Listening on Queues/Topics

• Compatibility for WLS 10.0 and Earlier-style Polling

• Use Transaction Batching
  MDB transaction batching allows several JMS messages to be processed in one container managed transaction. Batching amortizes the cost of transactions over multiple messages and when used appropriately, can reduce or even eliminate the throughput difference between 2PC and 1PC processing.
• MDB Thread Management
  Thread management for MDBs is described in terms of concurrency—the number of MDB instances that can be active at the same time. Review information about MDB concurrency.
• Best Practices for Configuring and Deploying MDBs Using Distributed Topics
  Message-driven beans provide a number of application design and deployment options that offer scalability and high availability when using distributed topics. Follow the best practices for configuring and deploying MDBs.
• Using MDBs with Foreign Destinations
  Review information on the behavior of WebLogic Server when using MDBs that consume messages from foreign destinations
• Token-based Message Polling for Transactional MDB Listening on Queues/Topics
  Token-based polling mechanism approach provides better control of the concurrent poller thread count under changing message loads. Transactional WebLogic MDB uses a synchronous polling mechanism to retrieve messages from JMS destinations. With synchronous polling, one or more WebLogic polling threads synchronously receive messages from the MDB's source destination and then invoke the MDB application's onMessage callback.
• Compatibility for WLS 10.0 and Earlier-style Polling
  In WLS 10.0 and earlier, transactional MDBs with batching enabled created a dedicated polling thread for each deployed MDB. This polling thread was not allocated from the pool specified by dispatch-policy, it was an entirely new thread in addition to the all other threads running on the system.

Use Transaction Batching

MDB transaction batching allows several JMS messages to be processed in one container managed transaction. Batching amortizes the cost of transactions over multiple messages and when used appropriately, can reduce or even eliminate the throughput difference between 2PC and 1PC processing.

See Transaction Batching of MDBs in Developing Message-Driven Beans for Oracle WebLogic Server.

• Using batching may require reducing the number of concurrent MDB instances. If too many MDB instances are available, messages may be processed in parallel rather than in a batch. See MDB Thread Management.

• While batching generally increases throughput, it may also increase latency (the time it takes for an individual message to complete its MDB processing).

MDB Thread Management

Thread management for MDBs is described in terms of concurrency—the number of MDB instances that can be active at the same time. Review information about MDB concurrency.

• Determining the Number of Concurrent MDBs

• Selecting a Concurrency Strategy

• Thread Utilization When Using WebLogic Destinations

• Limitations for Multi-threaded Topic MDBs

• Determining the Number of Concurrent MDBs
  
• Selecting a Concurrency Strategy
  
• Thread Utilization When Using WebLogic Destinations
  
• Limitations for Multi-threaded Topic MDBs
  

Determining the Number of Concurrent MDBs

Table 9-1 provides information on how to determine the number of concurrently running MDB instances for a server instance.

Table 9-1 Determining Concurrency for WebLogic Server MDBs

Type of work manager or execute queue	Threads
Default work manager or unconstrained work manager	varies due to self-tuning, up to Min(max-beans-in-free-pool,16)
Default work manager with self-tuning disabled	Min(default-thread-pool-size/2+1, max-beans-in-free-pool) This is also the default thread pool concurrency algorithm for WebLogic Server 8.1
Custom execute queue	Min(execute-queue-size, max-beans-in-free-pool)
Custom work manager with constraint	varies due to self-tuning, between min-thread-constraint and Min(max-threads-constraint, max-beans-in-free-pool)

Transactional WebLogic MDBs use a synchronous polling mechanism to retrieve messages from JMS destinations if they are either: A) listening to non-WebLogic queues; or B) listening to a WebLogic queue and transaction batching is enabled. See Token-based Message Polling for Transactional MDBs Listening on Queues/Topics.

Selecting a Concurrency Strategy

The following section provides general information on selecting a concurrency strategy for your applications:

Note:

Every application is unique, select a concurrency strategy based on how your application performs in its environment.

• In most situations, if the message stream has bursts of messages, using an unconstrained work manager with a high fair share is adequate. Once the messages in a burst are handled, the threads are returned to the self-tuning pool.

• In most situations, if the message arrival rate is high and constant or if low latency is required, it makes sense to reserve threads for MDBs. You can reserve threads by either specifying a work manager with a min-threads-constraint or by using a custom execute queue.

• If you migrate WebLogic Server 8.1 applications that have custom MDB execute queues, you can convert the MDB execute queue to a custom work manager that has a configured max-threads-constraint parameter and a high fair share setting.

  Note:

  You must configure the max-threads-constraint parameter to override the default concurrency of 16.

• In WebLogic Server 8.1, you could increase the size of the default execute queue knowing that a larger default pool means a larger maximum MDB concurrency. Default thread pool MDBs upgraded to WebLogic Server 9.0 will have a fixed maximum of 16. To achieve MDB concurrency numbers higher than 16, you will need to create a custom work manager or custom execute queue. See Table 9-1.

Thread Utilization When Using WebLogic Destinations

The following section provides information on how threads are allocated when WebLogic Server interoperates with WebLogic destinations.

• Non-transactional WebLogic MDBs allocate threads from the thread-pool designated by the dispatch-policy as needed when there are new messages to be processed. If the MDB has successfully connected to its source destination, but there are no messages to be processed, then the MDB will use no threads.

• Transactional WebLogic MDBs with transaction batching disabled work the same as non-transactional MDBs except for Topic MDBs with a Topic Messages Distribution Mode of Compatibility (the default), in which case the MDB always limits the thread pool size to 1.

• The behavior of transactional MDBs with transaction batching enabled depends on whether the MDB is listening on a topic or a queue:

  • MDBs listening on topics: — Each deployed MDB uses a dedicated daemon polling thread that is created in Non-Pooled Threads thread group.

    • Topic Messages Distribution Mode = Compatibility: Each deployed MDB uses a dedicated daemon polling thread that is created in the Non-Pooled Threads thread group.

    • Topic Messages Distribution Mode = One-Copy-Per-Server or One-Copy-Per-Application: Same as queues.

  • MDBs listening on queues — Instead of a dedicated thread, each deployed MDB uses a token-based, synchronous polling mechanism that always uses at least one thread from the dispatch-policy. See Token-based Message Polling for Transactional MDBs Listening on Queues/Topics.

For information on how threads are allocated when WebLogic Server interoperates with MDBs that consume from Foreign destinations, see Thread Utilization for MDBs that Process Messages from Foreign Destinations.

Limitations for Multi-threaded Topic MDBs

When the topicMessagesDistributionMode is Compatibility, the default behavior for non-transactional topic MDBs is to multi-thread the message processing. In this situation, the MDB container fails to provide reproducible behavior when the topic is not a WebLogic JMS Topic, such as unexpected exceptions and acknowledgement of messages that have not yet been processed. For example, if an application throws a RuntimeException from onmessage, the container may still acknowledge the message. Oracle recommends setting max-beans-in-free-pool to a value of 1 in the deployment descriptor to prevent multi-threading in topic MDBs when the topic is a foreign vendor topic (not a WebLogic JMS topic).

Caution:

Non-transactional Foreign Topics: Oracle recommends explicitly setting max-beans-in-free-pool to 1 for non-transactional MDBs that work with foreign (non-WebLogic) topics. Failure to do so may result in lost messages in the event of certain failures, such as the MDB application throwing Runtime or Error exceptions.

Unit-of-Order: Oracle recommends explicitly setting max-beans-in-free-pool to 1 for non-transactional Compatibility mode MDBs that consume from a WebLogic JMS topic and process messages that have a WebLogic JMS Unit-of-Order value. Unit-of-Order messages in this use case may not be processed in order unless max-beans-in-free-pool is set to 1.

Transactional MDBs automatically force concurrency to 1 regardless of the max-beans-in-free-pool setting.

Best Practices for Configuring and Deploying MDBs Using Distributed Topics

Message-driven beans provide a number of application design and deployment options that offer scalability and high availability when using distributed topics. Follow the best practices for configuring and deploying MDBs.

See Configuring and Deploying MDBs Using Distributed Topics in Developing Message-Driven Beans for Oracle WebLogic Server.

Using MDBs with Foreign Destinations

Review information on the behavior of WebLogic Server when using MDBs that consume messages from foreign destinations

Note:

The term "foreign destination" in this context refers to destinations that are hosted by a non-WebLogic JMS provider. It does not refer to remote WebLogic destinations.

• Concurrency for MDBs that Process Messages from Foreign Destinations

• Thread Utilization for MDBs that Process Messages from Foreign Destinations

• Concurrency for MDBs that Process Messages from Foreign Destinations
  
• Thread Utilization for MDBs that Process Messages from Foreign Destinations
  

Concurrency for MDBs that Process Messages from Foreign Destinations

The concurrency of MDBs that consume from destinations hosted by foreign providers (non-WebLogic JMS destinations) is determined using the same algorithm that is used for WebLogic JMS destinations.

Thread Utilization for MDBs that Process Messages from Foreign Destinations

The following section provides information on how threads are allocated when WebLogic Server interoperates with MDBs that process messages from foreign destinations:

• Non-transactional MDBs use a foreign vendor's thread, not a WebLogic Server thread. In this situation, the dispatch-policy is ignored except for determining concurrency.

• Transactional MDBs run in WebLogic Server threads, as follow:

  • MDBs listening on topics — Each deployed MDB uses a dedicated daemon polling thread that is created in Non-Pooled Threads thread group.

  • MDBs listening on queues — Instead of a dedicated thread, each deployed MDB uses a token-based, synchronous polling mechanism that always uses at least one thread from the dispatch-policy. See Token-based Message Polling for Transactional MDBs Listening on Queues/Topics

Token-based Message Polling for Transactional MDB Listening on Queues/Topics

Token-based polling mechanism approach provides better control of the concurrent poller thread count under changing message loads. Transactional WebLogic MDB uses a synchronous polling mechanism to retrieve messages from JMS destinations. With synchronous polling, one or more WebLogic polling threads synchronously receive messages from the MDB's source destination and then invoke the MDB application's onMessage callback.

Transactional WebLogic MDB uses a synchronous polling mechanism to retrieve messages from JMS destinations if they are:

• Listening to non-WebLogic queues

• Listening to a WebLogic queue and transaction batching is enabled

• Listening to a WebLogic Topic where:

  • Topic Messages Distribution Mode = One-Copy-Per-Server and transaction batching is enabled

  • Topic Messages Distribution Mode = One-Copy-Per-Application and transaction batching is enabled

As of WebLogic 10.3, the polling mechanism changed to a token-based approach to provide better control of the concurrent poller thread count under changing message loads. In previous releases, the thread count ramp-up could be too gradual in certain use cases. Additionally, child pollers, once awoken, could not be ramped down and returned back to the pool for certain foreign JMS providers.

When a thread is returned to the thread pool with token-based polling, the thread's internal JMS consumer is closed rather than cached. This assures that messages will not be implicitly pre-fetched by certain foreign JMS Providers while there is no polling thread servicing the consumer.

In addition, each MDB maintains a single token that provides permission for a given poller thread to create another thread.

• On receipt of a message — A poller thread that already has the token or that is able to acquire the token because the token is not owned, wakes up an additional poller thread and gives the token to the new poller if the maximum concurrency has not yet been reached. If maximum concurrency has been reached, the poller thread simply releases the token (leaving it available to any other poller).

• On finding an empty queue/Topic — A poller tries to acquire the token and if successful will try to poll the queue periodically. If it fails to acquire the token, it returns itself back to the pool. This ensures that with an empty queue or topic, there is still at least one poller checking for messages.

WebLogic 12.2.1.2.0 introduces two properties of type activation-configproperty: mdbDestinationPollIntervalMillis and minimizeAQSessions. The mdbDestinationPollInternvalMillis property controls the message polling interval that is used by the synchronous polling mechanism for MDB. When the JMS provider is AQJMS, the minimizeAQSessions property reduces the use of database resources by minimizing the number of AQ JMS sessions.

Compatibility for WLS 10.0 and Earlier-style Polling

In WLS 10.0 and earlier, transactional MDBs with batching enabled created a dedicated polling thread for each deployed MDB. This polling thread was not allocated from the pool specified by dispatch-policy, it was an entirely new thread in addition to the all other threads running on the system.

See Use Transaction Batching.

To override the token-based polling behavior and implement the WLS 10.0 and earlier behavior, you can either:

• At the server level, set the weblogic.mdb.message.81StylePolling system property to True to override the token-based polling behavior.

• At the MDB level, set the use81-style-polling element under message-driven-descriptor to override the token-based polling behavior. When using foreign transactional MDBs with the WLS 8.1-style polling flag, some foreign vendors require a permanently allocated thread per concurrent MDB instance. These threads are drawn from the pool specified by dispatch-policy and are not returned to the pool until the MDB is undeployed. Since these threads are not shared, the MDB can starve other resources in the same pool. In this situation, you may need to increase the number of threads in the pool. With the token-based polling approach for such foreign vendors, the thread's internal JMS message consumer is closed rather than cached to assure that messages will not be reserved by the destination for the specific consumer.