JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server Message Queue 4.5 Developer's Guide for Java Clients
search filter icon
search icon

Document Information

Preface

1.  Overview

2.  Using the Java API

3.  Message Queue Clients: Design and Features

Client Design Considerations

Developing Portable Clients

Choosing Messaging Domains

Connections and Sessions

Producers and Consumers

Assigning Client Identifiers

Message Order and Priority

Using Selectors Efficiently

Balancing Reliability and Performance

Managing Client Threads

JMS Threading Restrictions

Thread Allocation for Connections

Managing Memory and Resources

Managing Memory

Managing Message Size

Message Compression

Advantages and Limitations of Compression

Compression Examples

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

Factors Affecting Performance

Delivery Mode (Persistent/Nonpersistent)

Use of Transactions

Acknowledgment Mode

Durable vs. Nondurable Subscriptions

Use of Selectors (Message Filtering)

Message Size

Message Body Type

Connection Event Notification

Connection Events

Creating an Event Listener

Event Listener Examples

Consumer Event Notification

Consumer Events

Creating a Consumer Event Listener

Consumer Event Listener Examples

Client Connection Failover (Auto-Reconnect)

Enabling Auto-Reconnect

Single-Broker Auto-Reconnect

Parallel Broker Auto-Reconnect

Clustered-Broker Auto-Reconnect

Auto-Reconnect Behaviors

Auto-Reconnect Limitations

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

Failover Producer Example

Failover Consumer Example

Custom Client Acknowledgment

Using Client Acknowledge Mode

Using No Acknowledge Mode

Schema Validation of XML Payload Messages

Communicating with C Clients

Client Runtime Logging

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

5.  Working with SOAP Messages

6.  Embedding a Message Queue Broker in a Java Client

A.  Warning Messages and Client Error Codes

Index

Programming Issues for Message Consumers

This section describes two problems that consumers might need to manage: the undetected loss of a connection, or the loss of a message for distributed synchronous consumers.

Using the Client Runtime Ping Feature

Message Queue defines a connection factory attribute for a ping interval. This attribute specifies the interval at which the client runtime should check the client’s connection to the broker. The ping feature is especially useful to Message Queue clients that exclusively receive messages and might therefore not be aware that the absence of messages is due to a connection failure. This feature could also be useful to producers who don’t send messages frequently and who would want notification that a connection they’re planning to use is not available.

The connection factory attribute used to specify this interval is called imqPingInterval. Its default value is 30 seconds. A value of -1 or 0, specifies that the client runtime should not check the client connection.

Developers should set (or have the administrator set) ping intervals that are slightly more frequent than they need to send or receive messages, to allow time to recover the connection in case the ping discovers a connection failure. Note also that the ping may not occur at the exact time specified by the value you supply for interval; the underlying operating system’s use of i/o buffers may affect the amount of time needed to detect a connection failure and trigger an exception.

A failed ping operation results in a JMSException on the subsequent method call that uses the connection. If an exception listener is registered on the connection, it will be called when a ping operation fails.

Preventing Message Loss for Synchronous Consumers

It is always possible that a message can be lost for synchronous consumers in a session using AUTO_ACKNOWLEDGE mode if the provider fails. To prevent this possibility, you should either use a transacted session or a session in CLIENT_ACKNOWLEDGE mode.

Synchronous Consumption in Distributed Applications

Because distributed applications involve greater processing time, such an application might not behave as expected if it were run locally. For example, calling the receiveNoWait method for a synchronous consumer might return null even when there is a message available to be retrieved.

If a client connects to the broker and immediately calls the receiveNoWait method, it is possible that the message queued for the consuming client is in the process of being transmitted from the broker to the client. The client runtime has no knowledge of what is on the broker, so when it sees that there is no message available on the client’s internal queue, it returns with a null, indicating no message.

You can avoid this problem by having your client do either of the following: