1.0.0.1 Bugs

Fixes for Connectivity (Fabric)

Bug 5239 - BufferOverflowException or HttpInvalidMessageException when using Connection API

Sending a POST or PUT request to an HTTP or HTTPS service using the Connection API could result in intermittent exception in both outbound and inbound request processing.

One potential symptom was a java.nio.BufferOverflowException exception being thrown to the application using the Connection API to make the outbound HTTP request.

An alternative symptom was a zero.network.vendor.http.channel.exception.HttpInvalidMessageException reported for an apparently unrelated HTTP request arriving at the application. The following log messages may be associated with this second symptom:

CWPZC0128E: Failed to read buffer to completion, stream ended early

CWPZC0105E: An error with the client connection was caught, Could not fill buffer - stream ended early

The logic used to send POST or PUT bodies using the Connection API has been corrected to avoid this problem.

Bug 5653 - Connection destination matching URL normalisation incorrect

The Connection API destination matching algorithm for target resource URLs was incorrectly including the query. Target resource URLs will now discount query parameters and operate as documented. Only the protocol name, host name, port and file path will be considered; any user information, query or fragment specified in the target resource URL will be discounted when matching against configured connection destinations.

Bug 5657 - Fix Host: header for HTTP transport

The Host header generated by the Connection API for outbound HTTP requests unnecessarily included the default port number. This caused requests to be rejected by some servers. The port number will now only be included in the Host header when it was specified in the target URL requested by the application.

Fixes for Reliable Transport Extension (Messaging)

Bug 4889 - Automatic quiesce for store-and-forward flows

Item 1

The bridge connection manager now monitors messages that flow across an established store-and-forward pipe. If the flow from a store-and-forward queue remains idle for a specified period of time, the bridge connection manager will suspend it. Once all the flows associated with a pipe are suspended, the pipe will be disconnected. A suspended flow or pipe will be resumed after new messages arrive on the store-and-forward queue. The length of time the bridge connection manager will retain a flow for an idle store-and-forward queue can be specified using a new broker configuration property, /config/messaging/broker/bridgeIdleTimeout. The default value is 60 minutes.

Item 2

The maximum length for queue names has been increased from 20 to 79 characters. The new queue name length limit applies to:

• The "queue" protocol configuration parameter for the "messaging" protocol.
• The "queueName" configuration parameter for the messaging kicker.
• The target queue name in a store-and-forward queue name.

Item 3

The deliveryTimeout property of broker connections configured under /config/connection/messaging/brokerName was only being applied to connections to secured brokers. Connections to unsecured brokers were incorrectly adopting a value of 15 seconds resulting in potential "Return code=5" timeouts in higher load situations. The default deliveryTimeout of 60 seconds is now correctly applied to both secured and unsecured connections and can be specified as documented.

Item 4

The "priority" protocol configuration parameter is now included for the "messaging" protocol and can be when sending a message using the POST operation. The priority value must be in the range 0 (low) to 9 (high), inclusive, and the default value is 4. High priority messages will tend to be delivered before low priority messages.

Item 5

Messages store size configuration parameters have been removed from the documentation as they were ineffective. A new section has been added to the deployment notes and troubleshooting guide containing notes about how the message store may grow and how to mitigate against running out of storage.

Bug 5326 - Improved message priority support

The broker was only supporting two levels of message priority for each queue, which were mapped to JMS message priorities as follows: 0 mapped to "low" priority, 1 to 9 mapped to "high" priority (defect 122365). With this fix, the broker now supports ten separate levels of message priority, corresponding to the JMS message priorities.

If the fix is applied to an existing broker, the new priorities will be applied to existing queues and existing "high" priority messages will be placed on the new highest priority queue. These messages will continue to be delivered as highest priority until they are all consumed. However, new messages posted to the queue will then be delivered according to their relative priorities.

Fixpack Exit

• 1.0.0.1 Test