Skip Navigation Links | |
Exit Print View | |
Oracle GlassFish Server Message Queue 4.5 Developer's Guide for Java Clients |
3. Message Queue Clients: Design and Features
Balancing Reliability and Performance
Advantages and Limitations of Compression
Managing the Dead Message Queue
Managing Physical Destination Limits
Programming Issues for Message Consumers
Using the Client Runtime Ping Feature
Preventing Message Loss for Synchronous Consumers
Synchronous Consumption in Distributed Applications
Delivery Mode (Persistent/Nonpersistent)
Durable vs. Nondurable Subscriptions
Use of Selectors (Message Filtering)
Creating a Consumer Event Listener
Consumer Event Listener Examples
Client Connection Failover (Auto-Reconnect)
Parallel Broker Auto-Reconnect
Clustered-Broker Auto-Reconnect
Handling Exceptions When Failover Occurs
Handling Exceptions in a Transacted Session
Transacted Session: Failover Producer Example
Transacted Session: Failover Consumer Example
Handling Exceptions in a Non-Transacted Session
Schema Validation of XML Payload Messages
Logging Name Spaces, Levels, and Activities
Using the JRE Logging Configuration File
Using a Logging Configuration File for a Specific Application
Setting the Logging Configuration Programmatically
4. Using the Metrics Monitoring API
6. Embedding a Message Queue Broker in a Java Client
Using client threads effectively requires that you balance performance, throughput, and resource needs. To do this, you need to understand JMS restrictions on thread usage, what threads Message Queue allocates for itself, and the architecture of your applications. This section addresses these issues and offers some guidelines for managing client threads.
The Java Messaging Specification mandates that a session not be operated on by more than one thread at a time. This leads to the following restrictions:
A session may not have an asynchronous consumer and a synchronous consumer.
A session that has an asynchronous consumer can only produce messages from within the onMessage() method (the message listener). The only call that you can make outside the message listener is to close the session.
A session may include any number of synchronous consumers, any number of producers, and any combination of the two. That is, the single-thread requirement cannot be violated by these combinations. However, performance may suffer.
The system does not enforce the requirement that a session be single threaded. If your client application violates this requirement, you will get a JMSIllegalState exception or unexpected results.
When the Message Queue client runtime creates a connection, it creates two threads: one for consuming messages from the socket, and one to manage the flow of messages for the connection. In addition, the client runtime creates a thread for each client session. Thus, at a minimum, for a connection using one session, three threads are created. For a connection using three sessions, five threads are created, and so on.
Managing threads in a JMS application often involves trade-offs between performance and throughput. Weigh the following considerations when dealing with threading issues.
When you create several asynchronous message consumers in the same session, messages are delivered serially by the session thread to these consumers. Sharing a session among several message consumers might starve some consumers of messages while inundating other consumers. If the message rate across these consumers is high enough to cause an imbalance, you might want to separate the consumers into different sessions. To determine whether message flow is unbalanced, you can monitor destinations to see the rate of messages coming in. See Chapter 4, Using the Metrics Monitoring API.
You can reduce the number of threads allocated to the client application by using fewer connections and fewer sessions. However, doing this might slow your application’s throughput.
You might be able to use certain JVM runtime options to improve thread memory usage and performance. For example, if you are running on the Solaris platform, you may be able to run with the same number (or more) threads by using the following vm options with the client: Refer to the JDK documentation for details.
Use the Xss128K option to decrease the memory size of the heap.
Use the xconcurrentIO option to improve thread performance in the 1. 3 VM.