This chapter is from the book
This chapter is from the book
This chapter is from the book
JMS Best Practices
The following paragraphs describe some best practices for coding JMS applications.
Avoid Unneeded Features
JMS provides a powerful messaging facility with support for transactions, persistence, durable subscribers, and message selection and sorting. While these are important features of WebLogic's JMS implementation, they do affect the messaging system's performance. Selecting the correct acknowledgment mode or using nonpersistent messages where appropriate can greatly increase the throughput of a JMS application.
Avoid unnecessary features for maximum JMS performance.
Selection Performance Costs
JMS message selectors are a convenient and powerful means to filter messages from a queue or topic, but care must be taken to ensure that selection does not deter overall system performance.
Every JMS message sent to a destination must be compared against the consumers' message selectors. Message selectors that only consider message header fields will run the fastest. A selector that uses the message properties is slower, and if a selector examines the message body, it will be even slower.
Message selection is well suited to JMS topics. The WebLogic JMS implementation can efficiently evaluate the selectors and deliver the messages to the appropriate consumers. If no topic consumers select the message, it does not need to be retained.
Use selectors that only examine message header fields. A selector that examines message properties will be slower, and examining the message body produces the slowest message selectors.
However, message selection with queues can incur performance overheads if it is not used carefully. When a consumer does not select a message, it must be retained in the queue. Each selector must be compared against every undelivered message in the queue. If a message is never selected, it continues to consume resources.
Message selectors are more efficient when used with topics than queues.
Using Asynchronous Message Consumers Where Possible
JMS supports both synchronous and asynchronous message consumers. It is recommended that, where possible, asynchronous message consumers be used. Asynchronous message consumers provide better resource usage because threads are not blocked waiting for messages.
Synchronous message consumers always block a thread in the client. If the receive call is made from an external client, the WebLogic JMS implementation will not block a thread in the WebLogic Server. This is important for server scalability because the server cannot dedicate a blocking thread to each client. However, the thread in the client is blocked until the receive call returns.
If a synchronous receive call is made from within the WebLogic Server, a server thread must block until the receive call returns. Threads are valuable resources within a scalable server, and it is unacceptable to block these threads for long periods of time. Asynchronous consumers make better use of threads, especially within the server process.
Use asynchronous message consumers.
Prefer JTA Transactions to Transacted Sessions
Many JMS applications require transactional messaging. Transacted sessions provide a convenient means to use transactions within JMS, but other components such as EJBs or JDBC access cannot participate in these transactions. The JTA UserTransaction interface enables nontransacted sessions to participate in a transaction that can encompass other components, including JDBC or EJB. However, JMS does not provide a method to include an asynchronous consumer's message receipt in a JTA transaction. The problem is that there is no way to explicitly start a UserTransaction before the onMessage() callback. In this case, transacted sessions could be used or, as we'll see in Chapter 11, EJB's message-driven beans are asynchronous message listeners whose message receipt may optionally participate in a JTA transaction.
Use JTA UserTransactions rather than transacted sessions.
JMS Transactions and Error Handling
Large applications are often divided into multiple systems or separate processes, and JMS provides the communication between these subsystems. This workflow is PTP and is modeled with a queue. To ensure that messages are not lost, the JMS work is handled within a transaction. In production applications, it is possible that a message will contain application data that includes invalid data or errors. A transactional JMS client needs to be careful when handling invalid messages. If the transaction aborts, the message will be returned to the queue and delivered again to the consumer. Unless this error is transient, the second delivery will cause a transaction rollback, and the process continues.
One common solution is to introduce a separate error destination. When an invalid message is discovered, the message is sent to the error destination, and the JMS transaction commits. This ensures that the message is not redelivered. A message consumer on the error queue can handle the invalid messages appropriately. A simple solution is to use JavaMail to send an email to the customer or system administrator informing them of the error condition.
Send invalid messages to a separate error destination.
Another common solution separates the message acknowledgment from the JDBC or EJB transaction. This is desirable if the JDBC or EJB layer will detect that the message is invalid and abort the transaction. The message consumer needs to ensure that message is still acknowledged. The JMS consumer uses the CLIENT_ACKNOWLEDGE or AUTO_ACKNOWLEDGE modes. When a message is received, the transaction will begin; the JDBC or EJB work is performed within the transaction; and the message consumer commits or aborts the transaction.
Then, the message consumer acknowledges the message. This opens the possibility that the transaction will commit, but the system will fail before the message is acknowledged. The application can often prepare for this case by making the message actions idempotent or by detecting this situation. For instance, an e-commerce application might send a JMS message that processes new customer accounts. If each message includes a customer ID number, the message consumer can determine whether this customer has already been processed.