JIRA: https://jira.spring.io/browse/INT-3884
Previously, an outbound gateway within a chain allowed a `reply-channel` attribute
but it was ignored. The gateway's output channel is set to send the message to
the next element in the chain, or the chain's output channel if the gateway is
the last element.
Tighten the parser logic to detect and disallow a reply channel within a chain.
Polishing
MessagingTemplate had no timeout and could hang the build.
OnlyOneTrigger could fire before the message is sent; increase
the poller receive timeout so the poller thread blocks until the message is sent.
JIRA: https://jira.spring.io/browse/INT-3823
The test stops the endpoint.
The previous poller thread can 'steal' the `input` message, but since
it is interrupted, it can't send the message to the `publishedChannel`.
Add logic to wait until the previous poller has been interrupted in `receive()`.
Increase the endpoint `receiveTimeout` to ensure the thread will be interrupted.
Bump SF Version to 4.2.3
Remove `TRACE` logging from the `EnableIntegrationTests` since we have the fix already
Make some optimization around `@DirtiesContext`
* `ClientWebSocketContainer`: add some synchronization to avoid race conditions: https://build.spring.io/browse/INT-B41-492
* `TomcatWebSocketTestServer`: convert to `0` port to rely on the OS resolution for `localPort`
* Add `LogAdjustingTestSupport` for STOMP test
* `SftpServerTests`: use `0` port to rely on the OS resolution for `localPort`
* `ImapMailReceiver`, `OutboundGatewayFunctionTests` (JMS), `CachingClientConnectionFactoryTests`,
`AsyncGatewayTests`, `AsyncMessagingTemplateTests`, `GatewayParserTests`, `PriorityChannelTests`, `AggregatorIntegrationTests`: increase timeout
* `EnableIntegrationTests`: use `LogAdjustingTestSupport`
* `FileOutboundChannelAdapterParserTests`: rework `Thread.sleep()` with `CountDownLatch`
* `ConnectionToConnectionTests`: increase timeout and count iteration. Previously with `1sec` we may lose some events. And we can't just rely on the `10sec`,
because the last iteration will be so long
* `TcpOutboundGatewayTests`: `500ms` is so big timeout to wait for the `Exception` that in the high load environment we can yield to other Thread so long.
Like in our case to `server` Thread to send the reply for us. Therefore decrease the Exception timeout to the `50ms` and increase server delay to `2sec`
* `StompInboundChannelAdapterWebSocketIntegrationTests`: remove `@Qualifier("taskScheduler")` as a potential candidate to test against latest SF changes.
We're fine with `SF-4.2.2` and it is just a test-case. So, I don't see reason to wait for their fix here.
STOMP: `session = null` in adapters for any transportError
Polishing
JIRA: https://jira.spring.io/browse/INT-3882
Add reconnect support for the StompSession:
* Introduce `recoveryInterval` for the `AbstractStompSessionManager`
* Add reconnect scheduled task
* Add handling of the `ConnectionLostException` into the `AbstractStompSessionManager`,
as well as for the `StompInboundChannelAdapter` and `StompMessageHandler`
* Cover adapters reconnection feature with tests
* Documentation polishing
Rework logic according PR comments
* Make `StompMessageHandler` as a "lazy-load" for the connection
* Add "direct" connect interaction for the `AbstractStompSessionManager`
* Polishing tests
Polishing
Fix `StompAdaptersParserTests#testStompSessionManagerReconnect()` to use "fake" server port
Address PR comments
The further polishing
Some further polishing
* `AbstractStompSessionManager`: `reconnectFuture.cancel(true)` on each `scheduleReconnect()` to avoid something like "DDoS attack"
* Add reconnect feature test for the `StompInboundChannelAdapterWebSocketIntegrationTests`, closing and then refreshing again the `serverContext`
JIRA: https://jira.spring.io/browse/INT-3885
Possible dropped reply, causing timeout.
WARN org.springframework.integration.jms.JmsOutboundGateway#1.replyListener-1 jms.JmsOutboundGateway:1202
- Failed to consume reply with correlationId 164a49bf-c41d-4c0b-b012-55deecf001d1_2
java.lang.RuntimeException: No sender waiting for reply
- Reproduced by running the test in a loop
- Cleaned up test to aid debugging - capture a unique message at each stage
- Added additional debug logging to th gateway
Polishing
JIRA: https://jira.spring.io/browse/INT-3886
An SO user reported a short message delivery when an NIO connection was timed out.
See JIRA for link.
We could not produce the problem with his deserializer but it did identify a problem
with the standard `ByteArrayRawSerializer`.
With NIO, socket timeouts were reported to the deserializer as a normal EOF (-1). This
caused the raw serializer to emit a short message - it's signal for end of message is the
socket closure.
We can't treat a timeout as a normal EOF.
If the socket is forcibly timed out due to no recent data, throw a `SocketTimeoutException` to
the deserializer.
Just in case the old behavior is being relied upon, a boolean has been added to restore that
behavior. This is not recommended, as using timeout to delimit messages is not reliable.
* Fix typos
* Increase `MongoDbInboundChannelAdapterIntegrationTests` timeouts
* Some code polishing
Message producers are started in phase `Integer.MAX_INT / 2`.
The test case has a stomp inbound adapter and an event producer.
Since they are both in the same phase, the event producer can miss the `StompReceiptEvent`.
Change the phase of the event producer to ensure it is started before other message producers.
Examining the code revealed a possible (but improbable) NPE.
Checking the connection was disjoint from the publish; encapsulate the check within publish.
Synchronize the connectionLost method so it can't null the client while it is being checked.
Add `@SuppressWarnings("deprecation")` on the deprecated `connectIfNeeded()` usage.
Leadership was yielded before testing whether the adapter was started when leadership was granted.
It was possible for the adapter to be stopped again before testing `isRunning()`.
JIRA: https://jira.spring.io/browse/INT-3874
Previously the `IntegrationEvaluationContextFactoryBean` copied only those spel-functions which are defined
as beans in the ctx. Those which are specified through the `setFunctions` hasn't been copied from parent ctx to child.
This fix addresses and issue.
JIRA: https://jira.spring.io/browse/INT-3873
Phase I: add `Log4jLevelAdjuster` to the `StompInboundChannelAdapterWebSocketIntegrationTests` to have more info on the next CI failure.
https://build.spring.io/browse/INT-MJATS41-434
BindException.
Avoid using `findAvailableServerSocket()` where easily possible.
Some still remain, but they would require major rework of the tests.
Also fix a race in `TcpOutboundGatewayTests.testGoodNetGWTimeoutGuts()`. Although an
`AtomicBoolean` was used, both threads might still see the lower (500ms) timeout.
Polishing
JIRA: https://jira.spring.io/browse/INT-3831
- Add `@IntegrationManagedResource`
- Suppress exporting as an endpoint
Fix `outputChannel` issue for anonymous `MessagingGatewaySupport`
INT-3831: Pure JavaConfig Test
INT-3831: Polishing
Check output channel name for anonymous message source metrics.
Don't use getter on MGS to avoid early channel resolution.
INT-3831: Fix Test - Avoid Second MBeanServer
Reference the `MBSFB` in the context rather than create a new `MBeanServer`.
Polishing
JIRA: https://jira.spring.io/browse/INT-3859
The Java Mail `MessageCache.getMessageBySeqnum()` has the code:
````java
if (msgnum < 0) { // XXX - < 1 ?
if (logger.isLoggable(Level.FINE))
logger.fine("no message seqnum " + seqnum);
return null;
}
````
about which the `IMAPFolder.search` doesn't care:
````java
matchMsgs[i] = getMessageBySeqNumber(matches[i]);
````
therefore pops `null`s to the top for the `ImapMailReceiver`
* Fix `NPE` filtering the `Message[]` from `null` items
Note: its enough difficult to reproduce it because it isn't clear how we can end up with:
````java
if (seqnums[msgnum-1] > seqnum)
break; // message doesn't exist
````
in the `MessageCache`.
That's why there is no test-cases on the matter.
**Cherry-pick to 4.1.x**
Polishing
- Only create a new array if needed.
- Add a test case
* `JmsOutboundGatewayTests`: just increase timeouts. Looks like embedded ActiveMQ Broker takes more time to interact on high-loaded builds
* `TcpOutboundGatewayTests`: Rework the race condition fix to the atomic `remoteTimeout` change using mocks
* Modify `ControlBusTests.testControlHeaderChannelReaper()` do not rely on the `timeout`.
Make artificial expiration for the entry in the `registry` to allow `reaper` to remove it according the test logic.
* Fix race condition around `gateway.setRemoteTimeout(5000);` in the `TcpOutboundGatewayTests`.
The problem was that the gateway is called concurrently and `setRemoteTimeout` might be changed before the `handleMessage()` even for the first attempt.
The `ExtractRequestReplyPayloadTests` uses `3000` for `reply-timeout`.
This value might not be enough on high-loaded environment such a CI Server:
https://build.spring.io/browse/INT-B41-450
* Increase the timeouts for adapters to the `10000` to have more chances to pass on the CI.
* Some simple code polishing for the `ExtractRequestReplyPayloadTests`
