JIRA: https://jira.spring.io/browse/INT-3923Fixes: #2046
Previously, when connection is lost, the inbound adapter attempted to reconnect on
a schedule with a fixed delay.
If a connection was again lost, while the schedule is still running, we can end up
with another scheduled task running.
This is benign aside from the DEBUG log noise because the scheduled task tests the
connection before reconnecting.
However, if the `recoveryInterval` is short, it could consume CPU.
Change the reconnect to be a one-time scheduled task and reschedule if it fails to
reconnect.
Synchronize all access to the `connected` field.
Add a test case with a short recovery interval, before this fix, we see many logs
`Attempting reconnect`.
Conflicts:
spring-integration-mqtt/src/main/java/org/springframework/integration/mqtt/inbound/MqttPahoMessageDrivenChannelAdapter.java
spring-integration-mqtt/src/test/java/org/springframework/integration/mqtt/MqttAdapterTests.java
* Fix single-arg `Assert` method usage in the `AbstractCorrelatingMessageHandler`
JIRA: https://jira.spring.io/browse/INT-4221
* Upgrade to those versions of Spring project dependencies which potentially will provide similar fix
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4217
Previously, SpEL method calls with required header parameters had the following form:
#target.messageAndHeader(message, headers['number'] != null ? headers['number'] : T(org.springframework.util.Assert).isTrue(false, 'required header not available: number'))
The SpEL compiler cannot compile this because the else clause of the ternary has no `exitDescriptor` to indicate the type.
Change the expression to use a function for required headers.
Also use an Elvis operator when possible.
Some examples of new expressions:
#target.optionalAndRequiredHeader(headers['prop'] ?: null, #requiredHeader(headers, 'num'))
#target.optionalAndRequiredDottedHeader(headers['dot1'] != null ? headers['dot1'].foo : null,
#requiredHeader(headers, 'dot2').baz
In the second case, we can't use an Elvis because we're accessing a `foo` property of the header.
__cherry-pick to 4.3.x__
- make `ParametersWrapper` `static`
- minor conflicts in imports
- remove the perf test
* Polishing: remove redundant annotation args for their default values usage
* Revert `java.util.Optional` import in favor of literal for Java < 8
* Make `AnnotatedTestService` as `public` to get compilable SpELs
* Remove performance test from the `MethodInvokingMessageProcessorTests`
JIRA: https://jira.spring.io/browse/INT-4216
Add test for running empty array through `ChainFileListFilter`
Assure no exceptions are throw when filter input is empty.
INT-4216: Add fix for ChainFileListFilter edge case
INT-4216: Fix checkstyle error on test class
Add copyright header to test file
* Polishing for `ChainFileListFilter` JavaDocs
* Move `CompositeFileListFilterTests` and `ChainFileListFilterIntegrationTests` to the `filters` package instead of `file` core
(cherry picked from commit 1f9d07a)
JIRA: https://jira.spring.io/browse/INT-4212
Add an option to flush after the `flushInterval`, regardless of intermediate writes.
Rename `lastFlush` to `firstWrite`
Polishing
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4202
The `StoredProcOutboundGateway` uses `MessageBuilder` directly for procedure result without any conditions.
If procedure result is `null`, `MessageBuilder.withPayload` throws `java.lang.IllegalArgumentException: payload must not be null`.
* Since the super `AbstractReplyProducingMessageHandler` class takes care about `null` reply properly via its `requiresReply` property and really uses `MessageBuilder`
for reply, just fix `StoredProcOutboundGateway` to return procedure result as is from the `handleRequestMessage()` implementation
* Fix some typos and code style
* Increase some JDBC tests performance changing `Thread.sleep()` solution to proper `PollableChannel.receive()` or iterations over expected result
**Cherry-pick to 4.3.x**
Update `@Copyright` to 2017
Make `StoredProcOutboundGateway` as `requiresReply = true` by default
Revert `setRequiresReply(true)` change
Specify `setRequiresReply(true)` only if `expectSingleResult == true` and `setRequiresReply()` hasn't been called explicitly
Conflicts:
spring-integration-jdbc/src/main/java/org/springframework/integration/jdbc/StoredProcOutboundGateway.java
spring-integration-jdbc/src/test/java/org/springframework/integration/jdbc/JdbcMessageStoreChannelIntegrationTests.java
spring-integration-jdbc/src/test/java/org/springframework/integration/jdbc/config/StoredProcOutboundGatewayParserTests.java
Resolved.
JIRA: https://jira.spring.io/browse/INT-4203
Add channel names for easier use in DSL.
Add documentation (boot) example.
Normalize Expression Setters; add Javadocs
Polishing - SPR-15091
Tiny code style polishing
Conflicts:
spring-integration-core/src/test/java/org/springframework/integration/dsl/flows/IntegrationFlowTests.java
src/reference/asciidoc/handler-advice.adoc
spring-integration-core/src/test/java/org/springframework/integration/handler/advice/ExpressionEvaluatingRequestHandlerAdviceTests.java
* Restore removed methods in the `ExpressionEvaluatingRequestHandlerAdvice` and deprecate them
* Remove methods in the `ExpressionEvaluatingRequestHandlerAdvice` introduced since `5.0`
JIRA: https://jira.spring.io/browse/INT-4197
Since `Collection<Message<?>>` can be possible only if we are dealing with messages as a group (`MethodInvokingMessageListProcessor`), the case with the `List<?>` param for Messaging Annotation method should not be treated as candidate for `messages` collection.
* Add `this.canProcessMessageList` condition to avoid `messages` SpEL expression when we are not in the `MethodInvokingMessageListProcessor` environment
**Cherry-pick to 4.3.x**
* Fix Array creating formatting
* Add comment about `ReflectiveMethodExecutor` to the `testRouterWithListParam()`
* Send one test data as as `Collection` to be sure that `@Router` parameters mapping works well
JIRA: https://jira.spring.io/browse/INT-4201
name<->value alias was not processed correctly so using
`@Header(name = "baz") String baz` did not work.
Use `SynthesizingMethodParameter`.
(cherry picked from commit 0cbfd6e)
JIRA: https://jira.spring.io/browse/INT-4198
Enable setting properties like `needClientAuth` on the `SSLEngine` - when not using
NIO, this can be set on the server socket with a socket support implementation.
Add `nio-connection-support` to namespace.
Improved "Advanced Techniques" documentation, using this use case as an example.
Fail fast with NIO when SSL handshaking fails.
Polishing - PR Comments
More Polishing
* Final polishing
- fix several typos in log messages
- clean up `TcpConnectionFactoryFactoryBean` JavaDocs from redundant imports
- remove redundant `InitializationBean` functionality from the `DefaultTcpNetSSLSocketFactorySupport` as well
Conflicts:
spring-integration-ip/src/test/java/org/springframework/integration/ip/tcp/connection/SocketSupportTests.java
* Resolve Java 8 code style and revert `afterPropertiesSet()` with `@Deprecated`
Since we can have a result message in the `replyChannel` before the TX commit, a subsequent adapter `stop()` causes the current task interruption,
therefore TX rallback.
That's why we see `semaphore.acquire()` interruption and don't see message in the `afterCommitChannel`
**Cherry-pick to 4.3.x**
(cherry picked from commit bdab0aa)
There is tiny time window when `LockRegistryLeaderInitiator` can be stopped during `Context.yield()` invocation.
In this case the `LockRegistryLeaderInitiator` goes to the stopped state, but a new `leaderSelector` is submitted for election.
Therefore in the `LockRegistryLeaderInitiatorTests.competing()` the second initiator may not get be granted because there is uncontrolled `leaderSelector` task on background.
We can overcome it with always `this.initiator.stop()` for the `LockRegistryLeaderInitiatorTests`, but to be sure in the fix it would be better to leave as is.
Also add `@Rule Log4jLevelAdjuster` for future diagnostics
**Cherry-pick to 4.3.x**
(cherry picked from commit 56929cd)
No reason to load class one more time if `MethodMetadata` is already `StandardMethodMetadata`
See https://jira.spring.io/browse/SPR-14505
**Cherry-pick to 4.3.x**
(cherry picked from commit 1e46fb8)
https://build.spring.io/browse/INT-MJATS41-856
According the attempts to read method from class in the proper order, there is a fix in SF to do that via ASM.
Therefore `beanDefinition.getSource()` isn't `StandardMethodMetadata` any more.
Fortunately we can simply assert against `returnTypeName` to check for the `MessageHandler`
See https://jira.spring.io/browse/SPR-14505
**Cherry-pick to 4.3.x**
(cherry picked from commit f3460bd)
JIRA: https://jira.spring.io/browse/INT-4195
Avoid the N^2 search in `SequenceAwareMessageGroup` when the group is a
`SimpleMessageGroup`.
Avoid the use of the header accessor if the N^2 search is needed (SPR-15045).
Polishing - PR Comments
(cherry picked from commit a466579)
JIRA: https://jira.spring.io/browse/INT-4193
When using the internal `SequenceAwareMessageGroup` within an correlating
message handler, the messages were copied to a new collection before
checking for duplicate sequences in `canAdd()`.
This was unnecessary since we never add anything to this group, if `canAdd()`
returns true, the message is added to the store; this group is discarded.
Instead, use the message collection from the original group; although it is
not modifiable, this is not an issue because we don't need to modify it.
JIRA: https://jira.spring.io/browse/INT-4181
* To avoid duplicate code move actual `Metrics` resolution to the `IntegrationManagementConfigurer` and delegate from the `IntegrationMBeanExporter` for backward compatibility
* Minor refactoring and improvements in the `IntegrationMBeanExporter`
* Fix typos in the `jms/AsyncGatewayTests`
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4187
Add javadoc and test
- assertTrue on default adapter
- assertFalse check on nativeAdapter
- update XSD to add enable-status-reader
add `@auther`
add example in reference document
update adoc
* Fix minor typos in docs and allow to configure `enable-status-reader` with property placeholder
**Cherry-pick to 4.3.x**
(cherry picked from commit 16c7535)
https://build.spring.io/browse/INT-SI43X-60
After introduction the `sendErrorToListener()` function for the `TcpConnectionSupport`, all the tests in the `TcpNioConnectionReadTests` have flaw to be affected by the race condition to release semaphore in the `onMessage()` and don't get a connection as closed yet.
* Fix the tests adding `CountDownLatch` for the `ErrorMessage` and `AtomicReference` to assert an Exception message afterwards.
**Cherry-pick to 4.3.x**
Add Travis diagnostic to determine what is the difference if that
Revert Travis diagnostic
Looks like would be better to wait for CI failure to determine the root of sporadic cause
Conflicts:
spring-integration-ip/src/test/java/org/springframework/integration/ip/tcp/connection/TcpNioConnectionReadTests.java
JIRA: https://jira.spring.io/browse/INT-4185
Even if `WatchEventType` doesn't expose Java 7 API, its instantiation leads to the `StandardWatchEventKinds` object which already isn't Java 6
* Move `this.watchEvents = new WatchEventType[] { WatchEventType.CREATE }` to the ctor and guard it with the `ClassUtils.isPresent("java.nio.file.WatchService")`
Assertions for `WatchService`-based setters
JIRA: https://jira.spring.io/browse/INT-4183
Previously, this was hard-coded to 30 seconds.
* Fix typos according PR comments
Conflicts:
spring-integration-ip/src/main/java/org/springframework/integration/ip/config/IpAdapterParserUtils.java
spring-integration-ip/src/test/java/org/springframework/integration/ip/tcp/connection/SocketSupportTests.java
* Resolve conflicts for the `SocketSupportTests` where `ApplicationEventPublisher` isn't `@FunctionalInterface` yet in SF-4.3.x
Looks like there is some race condition around static fields in the `GemfireBeanFactoryLocator`
Also add `@DirtiesContext` to the `GemfireInboundChannelAdapterTests`
**Cherry-pick to 4.3.x and master**
(cherry picked from commit 90136d7)
JIRA: https://jira.spring.io/browse/INT-4178
The `JdbcLockRegistry` does not retry `CannotSerializeTransactionException` thrown by `DefaultLockRepository.acquire` which in turn causes `LockRegistryLeaderInitiator`s thread to get stuck.
* catch `CannotSerializeTransactionException` on `DefaultLockRepository.acquire` and ignore it to ensure a retry
**Cherry-pick to 4.3.x**
https://build.spring.io/browse/INT-MASTER-350
There are so much other similar `SocketUtils` usage and it doesn't look so quickly to fix them all
Let's do that on demand!
Or just live with rebuild forever to believe that it was just a bad luck...
Fix race condition when we assign the `port` for client before server actually has obtained the real port from OS
JIRA: https://jira.spring.io/browse/INT-4176
The `DelayerHandlerRescheduleIntegrationTests` doesn't close `context` in the end of test.
That causes clashes for `beanFactoryResolver` in other tests.
When those tests are fail, we come into condition when new processes can't be started/stopped because of effect of non-stopped context
* Fix all the `DelayerHandlerRescheduleIntegrationTests` to stop `context` in the end of test
* Remove unused files in the `gemfire/store` test package
* Add current date value to the `CacheServerProcess` name to avoid clashes with other ran on the same host
* Add NPE check for `region` in the `GemfireMetadataStoreTests`
* Extract `@BeforeClass/@AfterClass` for the `CacheWritingMessageHandlerTests` to start only one Gemfire cache per class
**Cherry-pick to 4.3.x & 4.2.x**
