Skip to content

Spring Integration 2.1 to 2.2 Migration Guide

Jump to bottom
garyrussell edited this page Dec 26, 2012 · 29 revisions

###spring-integration-remote Session Interface

The interface is used by FTP and SFTP modules; in 2.2 a new method was added

String[] listNames(String path);

This method was introduced in 2.1.1 on a temporary sub-interface

ExtendedSession<F>

to avoid breaking any user implementations.

This interface has now been removed and the method moved to

Session<F>

Any user Session implementations must implement this method, to return a simple array of Strings, containing the file names matched to the path. This method is used by the mget command.

###TCP Default Socket Timeout

Previously, when using a client connection factory with both outbound and inbound adapters, sockets created by that factory would get a default socket timeout of 10 seconds. This could be overridden by specifying a large timeout (2.0) or 0 (2.1).

In 2.2 and above, these sockets now get a default timeout of 0 (infinity). If you wish to restore the previous behavior, explicitly set the so-timeout attribute to 10000.

Note that single-use sockets created by a server connection factory continue to be configured with the default of 10 seconds if the so-timeout attribute is not configured.

###TCP Thread Pools with NIO

Previously, it was possible to hit an irrecoverable deadlock when using fixed thread pools (executors) when using NIO connections. This was more likely to happen when the pool was very small (just a few threads) or under very extreme conditions.

With the 2.2. release, we have added deadlock detection which will cause a connection to eventually fail if a thread is not available to handle the request, rather than hanging indefinitely. This type of thread starvation was a rare occurrence; we only had one user experience it when he set the pool size to just 2.

However, by necessity, the deadlock detection logic causes extra threads to be used at times, and so may require users with fixed thread pools, who haven't seen the issue, to slightly increase the pool size. Or, alternatively, use a cached thread pool, instead of a fixed thread pool.

You will immediately know if this situation has occurred if you see the following message:

"Timed out writing to pipe, probably due to insufficient threads in a fixed thread pool; consider increasing this task executor pool size"

###TCP Outbound Gateway reply-timeout

This attribute has been changed to be consistent with other gateways; it now reflects the time the gateway will wait to send the reply to the reply-channel, once it has been received. It only applies when the reply-channel might block (such as a bounded queue channel that is full).

A new attribute remote-timeout replaces the previous use of reply-timeout. This is the time the gateway will wait for a reply from the remote system.

For backwards compatibility, if just the reply-timeout is set, the remote-timeout will be set to the same value.

###ResequencingMessageGroupProcessor

Removed setComparator(..) method. See details in https://jira.springsource.org/browse/INT-2518

###HttpRequestExecutingMessageHandler (HTTP Outbound Gateway) (Milestone 3)

Changed the default response type from HttpStatus to org.springframework.http.ResponseEntity for more flexibility

###TCP ip_connection_seq Header Removed

Previously, this header (IpHeaders.CONNECTION_SEQ) was deprecated in favor of the standard sequenceNumber header, enabled by setting applySequence on the connection factory.

This header has now been removed; users relying on it should set applySequence and use the sequenceNumber header.

###Changes to LoadBalancingStrategy

See https://jira.springsource.org/browse/INT-1141

For performance reasons the LoadBalancingStrategy interface has been changed such that the getHandlers() method now returns a Set instead of a List.

###Delayer changes

Now delayer has ability to reschedule persisted Messages after the application restart. It caused such changes:

  • id attribute of <delayer> element is required. It is used with suffix '.messageGroupId' as Message Group identificator to store delayed Messages in the MessageGroupStore
  • default-delay requirement was removed: it's '0' by default. However one of (or both) default-delay and delay-header-name should be declared
  • wait-for-tasks-to-complete-on-shutdown was remove, as it is a property of provided ThreadPoolTaskScheduler
  • added JMX support for DelayHandler to control rescheduling of delayed persisted Messages at runtime

###Gateway timeout changes

Previously, the default timeouts (request/reply) on an annotated @Gateway method overrode the defaults configured in, say, XML. This behavior was unexpected.

Consider

<int:gateway ... default-request-timeout="1000" .../>

public interface Foo {
    @Gateway
    String bar(String baz);
}

The @Gateway attribute had a default value for requestTimeout of -1 (infinity), which would override the default. With this release, the default is now Long.MIN_VALUE, and this value does NOT override the default timeout.

This could be considered a breaking change for users that happened to use Long.MIN_VALUE in the annotation to explicitly override a default and use infinity. From this release forward, to revert to the old functionality, explicitly set the timeout on the annotation to some other negative value (e.g. -1).

###TCP Outbound Adapter Changes

Previously, errors sending messages to the TCP outbound adapter resulted in an ERROR log, but no exception was thrown. Starting with 2.2, a MessageHandlingException is thrown.

###<transactional> & <advice-chain> for <delayer> (Milestone 4) The <delayer> can be enriched with mutually exclusive sub-elements <transactional>and <advice-chain>. The List of these AOP Advices is applied to proxy internal handler DelayHandler.ReleaseMessageHandler, which has responsibility to release Message after delay in the Thread of scheduled task.

###HTTP Header Mapping

Placeholder - see INT-2524

###JDBC Message Store Changes

Placeholder - document schema changes

AmqpOutboundEndpoint: 'exchangeName' & 'routingKey' are now NULL by default

To simplify configuration, <amqp:outbound-gateway> & <amqp:outbound-channel-adapter> can be used without exchange-name(exchange-name-expression) and routing-key(routing-key-expression) attributes. In this case, publishing of the Message will use the values from the equivalent attributes of the configured RabbitTemplate. E.g.:

<rabbit:template id="amqpTemplate" connection-factory="rabbitConnectionFactory"
	exchange="default.exchange" routing-key="default.routing.key"/>

<amqp:outbound-channel-adapter id="amqpDefaultOutboundChannel"/>

Previously, omitting these attributes from the outbound endpoints overrode the template's attributes with "" . If you were relying on this behavior, you will now have to specifiy an empty string explicitly.

###object-to-json-transformer

The &<object-to-json-transformer/> now sets the content-type header to application/json, by default. It can be overridden using the content-type attribute. The default behavior has a side affect - causing applications with the following sequence to fail:

->object-to-json-transformer->amqp-outbound-adapter---->

---->amqp-inbound-adapter->json-to-object-transformer->

This is because the default SimpleMessageConverter used by the inbound adapter doesn't recognize this content type and the adapter emits a message with a byte[] payload instead of String.

If you are using this pattern, the simplest work around is to add a text content type to the transformer in the sending application; for example:

<object-to-json-transformer ... content-type="text/x-json"/>

###FTP/SFTP Gateways

Previously, filters (such as filename-pattern) were ignored on FTP and SFTP outbound gateways, except when used with the ls command. With 2.2, an exception is now thrown if a filter is configured for a gateway used with the get, mget and rm commands.

Clone this wiki locally