https://jira.spring.io/browse/INT-3665
Fixes according Travis report
Introduce `...ExpressionString(String)` setter
Some further fixes and polishing
Address PR comments
See https://jira.spring.io/browse/INT-3888 and its PullRequest
Note: rework `StompIntegrationTests` logic to use SockJS Client (that was enabled on the server side before).
This helps us to use `sessionId` which is as a `user` key on subscription phase.
In case of Standard Tomcat WebSocket Client we end up with the race condition when both client and server uses the same
`static` variable in the `WsSession` class, so we can't determine the server session correctly by the id on the client side.
The subscribe/send/unsubscribe logic works well because we are based on the **web socket** for the session, independently of its id.
* `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-3683
* In addition fix `inputs` for the Gradle `generateSql` task and regenerate all SQLs
to apply the typo fix.
The previous way to generate sql scripts doesn't work properly. It is always as `UP-TO-DATE`.
Adding `inputs` to the `generateSql` show the correct behaviour.
From other side that makes `cleanSql` task as redundant.
* Applying the Travis config fix to this commit as well.
Fix HTTP test timeout
https://build.spring.io/browse/INT-B41-346
Fix `ProducerAndConsumerAutoStartupTests`
https://build.spring.io/browse/INT-B41-346
Fix `DelayerUsageTests` `time` bean scope bug
https://build.spring.io/browse/INT-B41-347
Fix `HttpInboundGatewayParserTests.java` generics Java < 8 compiler warnings
Increase Tomcat response timeout for WebSocket tests
https://build.spring.io/browse/INT-B41-349
Increase timeout in the `AsyncMessagingTemplateTests#executionException()`
Fix `ClassCastException` for the `StandardWebSocketClient#userProperties`
Increase Delay to 2 Seconds in DelayHandlerTests
This should be treated as experimental but with these changes it seems to build ok.
BUILD SUCCESSFUL
Total time: 5 mins 15.533 secs
It turns out that our sporadic Redis problems were fixed in a later version of Jedis.
The problem was that the `connection.subscribe()` exited immediately. When I started adding debug
logic, the problem went away (because I was using a newer versio of Jedis).
spring-data-redis 1.5.2 is updated to work with the 2.7.3 version of Jedis.
Polishing
JIRA: https://jira.spring.io/browse/INT-3686
Since `WebSocketInboundChannelAdapter` is positioned as an adapter for WebSocket client side as well,
the appropriate Server-side frames should be handler properly there, too, even if `StompSubProtocolHandler`
isn't designed for the client side usage.
* Add catch of the `CONNECTED` and `RECEIPT` STOMP message types to the `WebSocketInboundChannelAdapter`
* Emit `CONNECTED` as a `SessionConnectedEvent`
* Emit `RECEIPT` as a new introduced `ReceiptEvent`
**Cherry-pick to 4.1.x**
More coverage for the new events stuff
JIRA: https://jira.spring.io/browse/INT-3580
* Uncomment `org.springframework.integration.ip` category for the IP tests `log4j.properties`
* Since all tests in the `StompIntegrationTests` uses the same application context and therefore the same `SubscriptionRegistry`
the `waitForSubscribe()` should wait exactly for that `subscription` in which it is interested in.
The previous fix wasn't enough
JIRA: https://jira.spring.io/browse/INT-3580
The test `StompIntegrationTests#handleExceptionAndSendToUser` sends `SUBSCRIBE` and `MESSAGE` messages at once.
Since Spring Websocket support relies on the `ExecutorSubscribableChannel` for `clientInboundChannel`, there is no guaranty that messages are processed
with the same order as they have been sent.
From other side `UserDestinationMessageHandler` shifts messages to the `brokerChannel`, which is an another `ExecutorSubscribableChannel` with its own `Executor`.
Hence there is some race condition when the second message can be handled before the first one.
Add `check subscription` cycle to wait until the `SUBSCRIBE` message registers its subscription to the Broker.
And only after that send the `MESSAGE` message.
JIRA: https://jira.spring.io/browse/INT-3515
Change test suite to the Tomcat according IO
INT-3515: IllegalStateException for the `WebSocketInboundChannelAdapter`, when `useBroker = true`, but there is no Broker Relay in the Context
JIRA: https://jira.spring.io/browse/INT-1198
INT-1198: WebSocket: Add namespace support
Polishing components according to the namespace support experience
Parser for `<server-container>` and tests
INT-1198: Add parser tests for `<int-websocket:outbound-channel-adapter>`
Introduce `use-broker` on server side
Polishing according PR comments
`What's New` note
JIRA: https://jira.spring.io/browse/INT-1197
INT-1197: Add JavaDocs and some polishing
Further changes
* Upgrade to SF 4.1
* Rename `SubProtocolHandlerContainer` to the `SubProtocolHandlerRegistry`
* Add `MessageConverter` support to the adapters
* Add `ClientWebSocketContainer.openConnectionException` to be thrown on `getSession` request
* Add `ClientWebSocketContainer.connectionLatch` to wait the connection establishing on first request.
Since the WebSocket connection process is run in the separate Thread, we need to wait it from the first `message send` do not lose the message, if connection hasn't been established yet.
INT-1197: Add `PassThruSubProtocolHandler`
Add `StompIntegrationTests`
INT-1197: Polishing according PR comments
INT-1197: Use SockJs from tests
Fix other detected vulnerabilities
INT-1197: `@Gateway` with `@MessageMapping` test
INT-1197: PR comments
Skip non `SimpMessageType.MESSAGE` to send to the `outputChannel` from `WebSocketInboundChannelAdapter`
Polishing
