e4722de464
A connection used by a gateway may timeout prematurely. Previously, the socket read timeout simply controlled when a socket would be closed after the timeout occurred. Consider a connection with so-timeout set to 10 seconds; the application initializes at T+0 and the first message is sent, with the server responding immediately; the timeout clock starts. Next, a message is sent at T+5 to a service that takes 6 seconds to respond. The connection will timeout at T+10 before the response is received; the socket is closed and client does not receive the response. The solution is to wait 2 timeout cycles *IF* a message has been sent within the current timeout. Maintain a timer for the last send() operation. When a socket timeout occurs, examine the last sent time; if within the timeout, defer the close until the next timeout. We cannot simply rely on the last send time because, when using collaborating adapters, continuous sends (with no replies) would defer the close indefinitely. Hence, the second test looking to see if we have not had a successful read for the last 2 timeouts. NIO does not directly support socket timeouts (because there is no thread hanging on the read); instead, the timeout logic is performed on the selector thread. Rename DefaultTimeoutTests to ConnectionTimeoutTests. Add tests (for both Socket and NIO connections) to assert the correct operation when a send is performed within a timeout, as well as when the server takes > 2x the timeout to respond. INT-2860 Fix Typo in Exception Message Error sending meeeage. removed invalid comment from test (while merging)
Spring Integration
Checking out and Building
To check out the project and build from source, do the following:
git clone git://github.com/SpringSource/spring-integration.git
cd spring-integration
./gradlew build
If you encounter out of memory errors during the build, increase available heap and permgen for Gradle:
GRADLE_OPTS='-XX:MaxPermSize=1024m -Xmx1024m'
To build and install jars into your local Maven cache:
./gradlew install
To build api Javadoc (results will be in build/api):
./gradlew api
To build reference documentation (results will be in build/reference):
./gradlew reference
To build complete distribution including -dist, -docs, and -schema zip files (results will be in build/distributions)
./gradlew dist
Using Eclipse
To generate Eclipse metadata (.classpath and .project files), do the following:
./gradlew eclipse
Once complete, you may then import the projects into Eclipse as usual:
File -> Import -> Existing projects into workspace
Browse to the 'spring-integration' root directory. All projects should import free of errors.
Using IntelliJ IDEA
To generate IDEA metadata (.iml and .ipr files), do the following:
./gradlew idea
OSGI Notes
- Dependency on Third Party Bundles Some adapters depend on third party libraries (bundles). Spring hosts the Enterprise Bundle Repository (EBR) at https://ebr.springsource.com/repository/app/, where you can download many third-party JARs as valid OSGi bundles. If a particular bundle is not available in Spring's EBR, there are tools that can convert a regular JAR to a bundle JAR. One of them is Bundlor http://www.springsource.org/bundlor which can auto-generate an OSGi MANIFEST.MF as part of standard project lifecycle or simply convert a non-bundle JAR to a bundle JAR.
- Boot delegation Some adapters depend on extension packages that are available to the boot class loader. As a case in point, the Feed Adapter depends on com.sun.syndication.feed. Since by default OSGi only loads java.* from the boot class loader, other packages that must be loaded from the boot class loader can therefore be specified with the 'org.osgi.framework.bootdelegation' System property. For example: org.osgi.framework.bootdelegation=com.sun.,org.w3c.. . . .
Resources
For more information, please visit the Spring Integration website at: http://www.springsource.org/spring-integration