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


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


Schema Validation of XML Payload Messages

This Message Queue feature enables validation of the content of a text (not object) XML message against an XML schema at the point the message is sent to the broker.

When XML validation is enabled, the Message Queue client runtime will attempt to validate an XML message against specified XSDs before sending the message to the broker. The location of the XML schema (XSD) is specified as a property of a Message Queue destination. If the specified schema cannot be located or the message cannot be validated, the message is not sent, and an exception is thrown.

If no XSD location is specified, the DTD declaration within the XML document is used to perform DTD validation. (XSD validation, which includes data type and value range validation, is more rigorous than DTD validation.)

Client applications using this feature should upgrade Java SE version to JRE 1.5 or above.

XML schema validation is enabled using the following physical destination properties: validateXMLSchemaEnabled, XMLSchemaURIList, and reloadXMLSchemaOnFailure. These properties are described in Chapter 18, Physical Destination Property Reference, in Oracle GlassFish Server Message Queue 4.5 Administration Guide. The property values can be set at destination creation or update time by using the imqcmd create dst or imqcmd update dst command, respectively. The XML validation properties should be set when a destination is inactive: that is, when it has no consumers and producers, and when there are no messages in the destination.

If any of the XML validation properties are set while a destination is active (for example, if a producer is connected to the destination), the change will not take effect until the producer reconnects to the broker. Similarly, if an XSD is changed, as a result of changing application requirements, all client applications producing XML messages based on the changed XSD must reconnect to the broker.

If the reloadXMLSchemaOnFailure property is set to true and XML validation fails, then the Message Queue client runtime will attempt to reload the XSD before attempting again to validate a message. The client runtime will throw an exception if the validation fails using the reloaded XSD.