JIRA https://jira.spring.io/browse/INT-4490
The `DefaultLockRepository.prefix` can be configured with the schema name.
And this one can be case-sensitive.
* Change format hint from the `%S` to `%s` to avoid upper-casing.
**Cherry-pick to 5.0.x and 4.3.x**
* GH-2467: JdbcLockRegistry should retry on DeadlockLoserDataAccessException
Fixes#2467
MySQL 5.7.15 introduced setting `innodb_deadlock_detect` (enabled by
default). As a result MySQL JDBC driver throws
`DeadlockLoserDataAccessException` when deadlock is detected.
`JdbcLockRegistry` doesn't handle it causing lock to be lost.
* Retry `doLock()` on data access deadlock instead of loosing the lock
* Use TransientDataAccessException instead of derived exceptions
(cherry picked from commit 4bb1a61)
JIRA: https://jira.spring.io/browse/INT-4477
When running multiple roles, it is useful to be able to determine the
role for a particular context, e.g. in an event.
* Docs
**cherry-pick to 5.0.x**
(cherry picked from commit 73dbdb8)
https://build.spring.io/browse/INT-FATS5IC-497
Fixes `JdbcMessageStoreTests` sporadic failure where there is no
guarantee that message are going to be polled from the group the same
order they've been inserted
Cherry-pick to `5.0.x`
(cherry picked from commit 664d67f)
Looks like Derby is much slower than H2, plus it doesn't look so stable
having so much sporadic failures.
Looks like moving to H2 here saves for us `500 ms` test working time
**Cherry-pick to 5.0.x**
(cherry picked from commit 6dfe96d)
The message in the `QueueChannel` appears for consuming a bit earlier
than TX is committed
* Introduce `afterCommitLatch` into the test verify the state
when TX is really committed and data is removed from DB
**Cherry-pick to 5.0.x and 4.3.x**
(cherry picked from commit e4e4ee0)
Looks like we have started to fail much often
since upgrade to the `Derby-10.14.1.0`:
cb0d43db6b
That is also related to this https://jira.spring.io/browse/INT-4445
* Remove all the `drop` mentioning for Derby scripts -
it just doesn't support `IF EXISTS`.
More over we don't need to worry about drops since each test now starts
its own fresh embedded DB
**Cherry-pick to 5.0.x**
JIRA: https://jira.spring.io/browse/INT-4447
When we get an exception during `this.lock.unlock()`, we don't revoke
leadership.
In case of external resource (e.g. JDBC) this may cause a race condition
when the second candidate is selected as leader when connection comes back
* Catch `this.lock.unlock()` exceptions and log them under DEBUG.
This way we proceed to the `handleRevoked()` logic
**Cherry-pick to 5.0.x and 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4445
Looks like `/dataSource` temporary directory is busy in between different
tests.
The thought is like a high-frequently polling endpoint keeps DB resource
from removing.
* Explicitly `stop()` endpoint in the `JdbcMessageStoreChannelTests`
* Optimize
`JdbcMessageStoreChannelTests.testSendAndActivateTransactionalSend()`
to rely on the short `1` millisecond TX timeout.
This safes for us 10 seconds of the tests executions.
* Configure all the embedded DB beans for the `ignore-failures="ALL"`
as a fallback option if polling endpoint is not a cause of the concurrent
resource access.
**Cherry-pick to 5.0.x**
https://build.spring.io/browse/INT-FATS5IC-457
The H2 `1.4.197` has fixed some issues
(in particular https://github.com/h2database/h2database/issues/178)
and introduced some breaking changes for us, although they are
reasonably good.
* Fix `JdbcOutboundGatewayParserTests` to use correct identifiers
for returned generated keys instead of previously used `SCOPE_IDENTITY()`
**Cherry-pick to 5.0.x and 4.3.x**
(cherry picked from commit 7b86ca7)
https://build.spring.io/browse/INT-AT42SIO-820/
The test configs use `fixed-rate="100"`.
This way when Inbound Channel Adapter is declared earlier in the
config than `<jdbc:embedded-database>`, there is a chance that we start
to poll DB before it is really initialized.
* Reorder config so embedded DB is initialized before an
Inbound Channel Adapter
**Cherry-pick to 5.0.x, 4.3.x and 4.2.x**
(cherry picked from commit da6f47c)
https://build.spring.io/browse/INT-FATS5IC-430
Looks like there is a race condition when our polling rate around
data base is too fast and we have access to the DB files even during
application context close.
* Stop polling channel adapter in the tests explicitly after test methods
* Increase some tests performance decreasing timeouts to wait
* Upgrade to Reactor-3.1.5, AssertJ-3.9.1, Derby-10.14.1.0 and some
Gradle plugins
* Upgrade to `reactor-netty-0.7.5`
* Remove workaround from the `StompServerIntegrationTests`
* Upgrade to Spring Data Kay SR5
* Upgrade to Spring Security 5.0.3
* Increase timeouts and performance in the `StreamTransformerParserTests`
JIRA: https://jira.spring.io/browse/INT-4396
When target distributed `Lock` implementation throws an exception, e.g.
in case of no connection to the service, the `LockRegistryLeaderInitiator`
exists the loop and can come back to the elections only after restart
* Catch all the exception on `this.lock.tryLock()` and resubmit
`LeaderSelector` for a new locking cycle if
`LockRegistryLeaderInitiator.isRunning()` and `InterruptedException`
* Remove diagnostics from the `JdbcLockRegistryLeaderInitiatorTests`
since this fix confirms that we just didn't have a reconnect logic before
when this test failed sporadically
**Cherry-pick to 4.3.x**
https://build.spring.io/browse/INT-MJATS41-1242
When different `DefaultLockRepository` instances use the same client id,
there is a possibility that they will update the same row in the table.
This way we have a chance that not only one obtains a lock and try to
add a value to the collection.
* Remove the test-case for the same client id as non-stable and even
dangerous by the the distributed lock purpose
* Use `tryLock(Long.MAX_VALUE)` to really ensure the wait behavior
during the concurrent loop
* Use `20` for thread pool to align with the tasks amount
**Cherry-picked to 4.3.x**
https://build.spring.io/browse/INT-MASTER-901
The `JdbcLockRegistryDifferentClientTests.testOnlyOneLock()` relies
on the `ArrayList.isEmpty()` state to proceed with the logic.
But since the `ArrayList.size` property is not `volatile`, there is no
guarantee for the proper state in the multi-threaded environment like
we have in this test-case.
* Replace `ArrayList` in the test with the `LinkedBlockingQueue` which
already rely on the `AtomicInteger` for the `size` property
* Fix `JdbcLockRegistry` tests to shutdown used `ExecutorService` s
to ensure set free threads after test suite execution.
**Cherry-pick to 4.3.x**
* INT-4376: Upgage to Log4J 2
JIRA: https://jira.spring.io/browse/INT-4376
* Deprecate Log4J 1.x components in favor of newly added
a `Log4j2LevelAdjuster` JUnit `@Rule`
* Update all the logging configuration to Log4J 2
* Polishing after testing
JIRA: https://jira.spring.io/browse/INT-2576
* Do not fetch message ids and then iterate over them to remove
one by one - just use an appropriate `DELETE` query for all messages
JIRA: https://jira.spring.io/browse/INT-4291
* Fix code style in the `ExpressionEvaluatingSqlParameterSourceFactory`
* Remove redundant
`ExpressionEvaluatingSqlParameterSourceFactory.registerSqlTypes` in
favor of the direct access to the `sqlParametersTypes` from the
`ExpressionEvaluatingSqlParameterSource` ctor
* Reformat code style in the `pollingWithSelectParameterSourceJdbcInboundChannelAdapterTest.xml`
* Fix code style in the `ExpressionEvaluatingSqlParameterSourceFactoryTests`
* Polishing `whats-new.adoc` for proper formatting and single link from
the section to the particular chapter
* Fix formatting and wording in the `jdbc.adoc`
JIRA: https://jira.spring.io/browse/INT-4291
* Fix checkstyle trailing space
*Use correct way to constants in spring xml and fix test case
* Polishing - Update javadoc and rename method name to relate more to the behavior
* Upgrade to SF-5.0.1, Reactor-3.1.1, some other minor upgrades
* Fix `HttpDslTests` and `WebFluxDslTests` for the latest SS compatibility
* Fix JavaDoc in the `ChannelMessageStorePreparedStatementSetter`
JIRA: https://jira.spring.io/browse/INT-4081
* Rename `MessageGroupPreparedStatementSetter` to `ChannelMessageStorePreparedStatementSetter`
* Add JavaDocs to the `ChannelMessageStorePreparedStatementSetter`
* Polishing `JdbcChannelMessageStore` JavaDocs; remove unused `BeanFactory`
* Polishing Docs for typos and proper text flow
JIRA: https://jira.spring.io/browse/INT-4081
* Add `MessageGroupPreparedStatementSetter` to let end-user to override
the message insertion logic
* Add tests and Docs
JIRA: https://jira.spring.io/browse/INT-4357
Updated based on code review.
Updated adocs
*Polishing code style, typos
* Add protection from NPE when `LockRegistryLeaderInitiator` isn't
supplied with the `leaderEventPublisher`
* Add `What's New` note
JIRA: https://jira.spring.io/browse/INT-4342
Use similar code to Spring AMQP to add white list support for Integration's
use of the `DeserializingMessageConverter`; introduce the `WhiteListDeserializingMessageConverter`.
Polishing
Missed this change in PR.
Fix XSD attribute
JIRA: https://jira.spring.io/browse/INT-4300
* Add `ReactiveHttpInboundEndpoint` based on the WebFlux foundation
* Extract `BaseHttpInboundEndpoint` for common
HTTP Inbound Channel Adapters options
* Make `spring-webmvc` and `spring-webflux` as `optional` dependencies
to let end-user to choose
* Refactor `HttpContextUtils` to include constants
for newly added WebFlux support
* Introduce `BaseHttpInboundEndpoint.setRequestPayloadTypeClass()`
for raw `Class<?>` and modify existing `setRequestPayloadType()`
for the `ResolvableType`
* Refactor existing MVC tests and XML components parsers to use
new `setRequestPayloadTypeClass()`
* Add `MessagingGatewaySupport.sendAndReceiveMessageReactive()` to get
a reply from downstream flow reactive back-pressure manner
* Add `IntegrationHandlerResultHandler` implementation to let WebFlux
infrastructure to handle the `Mono<Void>` from the `ReactiveHttpInboundEndpoint`
properly
* Fix `JdbcLockRegistryLeaderInitiatorTests` race condition to assert
the `initiator1` is elected eventually after yielding when the `initiator2`
is stopped
* Fix JavaDocs issue in the `HttpRequestHandlingMessagingGateway`
* Move all the "hard" logic in the `MessagingGatewaySupport#doSendAndReceiveMessageReactive`
to the `Mono` chain ensuring back-pressure when `sendAndReceiveMessageReactive()` is
called not from the Reactive Stream
Add test-case to demonstrate SSE
JIRA: https://jira.spring.io/browse/INT-3625
Some polishing and optimization for the
`MessagingGatewaySupport.doSendAndReceiveMessageReactive()`
More optimization for `MessagingGatewaySupport`
* Upgrade to Reactor 3.1 M3
* Document WebFlux-based components
Minor Doc Polishing
JIRA: https://jira.spring.io/browse/INT-4308
* Document `JdbcMetadataStore`
* Remove unnecessary context DERBY config for the `PersistentAcceptOnceFileListFilterExternalStoreTests`
* Rework the `testFileSystemWithJdbcMetadataStore()` to use `EmbeddedDatabase` directly, without context
JIRA: https://jira.spring.io/browse/INT-4311
* Added `QueryTimeoutException` to retry handling in the `JdbcLockRegistry`
Polishing
**Cherry-pick to 4.3.x**
JIRA: https://jira.spring.io/browse/INT-4306
Fixed checkstyle errors
Fixed checkstyle errors
Fixed checkstyle errors and sql schema
Manually fixed derby sql schema
Fixing some issues
added region support
small refactorings
test checkstyle fix
integration tests and fixes
integration tests and fixes
JIRA: https://jira.spring.io/browse/INT-4262
Since MySQL doesn't have `IF EXISTS` for `DROP INDEX`.
And on the other hand the entire `DROP TABLE` takes care about indexes as well,
we don't need the `DROP INDEX` command for mysql.properties
* Add `NODROPINDEX` variable to the `mysql.properties`
* Tweak `destroy.sql.vpp` to leverage `NODROPINDEX`
This commit harmonizes `LockRegistry#obtain` logic in Zookeeper and JDBC
implementations with Redis implementation
by using Java 8 `ConcurrentMap#computeIfAbsent`
* Remove `synchronized (this.locks)` from the `expireUnusedOlderThan`
implementations because `iterator()` is thread-safe from `ConcurrentHashMap`
* Fix deprecation in the `IntegrationGraphControllerRegistrar`
* Revert Spring Security version to `4.2.2`, since `5.0 B-S` is broken
JIRA: https://jira.spring.io/browse/INT-2625,
https://jira.spring.io/browse/INT-4050,
https://jira.spring.io/browse/INT-4052
Make some refactoring for consistency:
- Move `JdbcMessageStore` to the `store` package
- Make `JdbcMessageStore` only ctor-based configuration for the `JdbcOperations`
- Remove `/channel/` SQL scripts in favor of combined in the `/jdbc/` directory
- Make scripts for the `INT_CHANNEL_MESSAGE` table and indexes generated via VPP
Fix drop script generation
Fix `schema-derby.sql` for suspicious `[]`
Looks like `foundrylogic.vpp` tool generates somehow wrong SQL
Further fix for the `drop` scripts generation
Address PR comments:
* Remove deprecated code in the `JdbcMessageStore`
* Remove separate MySQL script in favor of only one for latest version
* Remove the note in the `jdbc.adoc` about recommendation to use new MySQL version
JIRA: https://jira.spring.io/browse/INT-4251
MockIntegration PoC
Demonstrate how `MockIntegration.mockMessageSource()` can be used.
Even from the XML Config!
The same semantics can be applied for any other our mocking features we will add to the `MockIntegration`
Add `testMockMessageSourceDynamicFlow()`
Improve `MockIntegration.Context.instead()` for target bean type assertion
Some refactoring, improvements and JavaDocs
* Move `MockIntegration.Context` to its own `MockIntegrationContext` class
* Rename `@MockIntegrationTest` to `@SpringIntegrationTest` since we talk there not only about mocks, but any other possible testing feature for integration
* Add `@SpringIntegrationTest#stopEndpoints()` attribute for endpoints bean names patterns
* Add `IntegrationEndpointsInitializer` to customize `AbstractEndpoint`s according options from the `@SpringIntegrationTest`
Right now it is only about making them `autoStartup = false`
* Rename `SI-test` to `SI-test-support`
* Rename `SI-mock` to `SI-test`
* Rename `@SpringIntegrationTest#stopEndpoints()` to `noAutoStartup()`
* Fix JavaDocs according PR comments
* Increase timeouts in some sporadically failed tests
* Draft for the `testing.adoc`
Fixesspring-projects/spring-integration-java-dsl#23
Fix `testing.adoc` a bit
* Document Testing Support
* Fix a couple typos in the `xml.adoc`
* Add `package-info.java` files to `/test/` sub-packages
Improve docs according PR comments
Fix typos in `TestUtils` JavaDocs
Add `What's New` note about Java DSL and Testing support
Doc Polishing
JIRA: https://jira.spring.io/browse/INT-4244
The `JpaOutboundGateway` returns a whole `Message` for reply copying request headers.
Building the reply a `AbstractMessageProducingHandler` uses `MessageBuilder` to create a new `Message` with all request headers because of `shouldCopyRequestHeaders() == true`
* To avoid some overhead with new `Message` and `MessageBuilder` for nothing, just return a JPA result as is and let super class to build the Message
* Optimize all reply producers to return `MessageBuilder` to the super `handleMessage()` process
* Return the whole `gatherResult` `Message<?>` from the `ScatterGatherHandler` to have ability to transfer reply headers as well
* Mark `DelayHandler` as `shouldCopyRequestHeaders() return false` since it doesn't modify Message and returns it as is after delay
JIRA: https://jira.spring.io/browse/INT-4246
The `LockRegistryLeaderInitiator` currently does not revoke leadership
when leading instance is unable to acquire lock from the underlying lock.
This can result in multiple `LockRegistryLeaderInitiator` instances becoming
leaders in the exceptional situations such as lock timeouts.
* Handle leadership revoking when leading `LockRegistryLeaderInitiator`
is unable to acquire lock
Polish javadoc
**Cherry-pick to master**
Conflicts:
spring-integration-core/src/main/java/org/springframework/integration/support/leader/LockRegistryLeaderInitiator.java
spring-integration-core/src/test/java/org/springframework/integration/support/leader/LockRegistryLeaderInitiatorTests.java
* Stop initiators in the end of test
JIRA: https://jira.spring.io/browse/INT-4220
Currently when an error is thrown from the event publishing the role granting is broken and we just go to the role revoking.
* Since it's just an event publishing it shouldn't effect the original leader election.
* `try...catch` event publishing in the `LeaderInitiator` and `logger.warn` an `Exception`
* Make `leader/Context` as `@FunctionalInterface` for simple Lambda use-case like `NULL_CONTEXT` - `() -> false`
* Remove all the internal `NullContext` implementations in favor of above mention Lambda
* In the `LockRegistryLeaderInitiator` use `CustomizableThreadFactory` instead of custom `ThreadFactory` for prefixing
* Add `zookeeper/leader/LeaderInitiator#getContext()` for external usage and consistency with other similar components
* Fix `CuratorContext.toString()` typo
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
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**
(cherry picked from commit 8198ff1)
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**
https://sonar.spring.io/component_issues?id=org.springframework.integration%3Aspring-integration%3Amaster#resolved=false|types=BUG
In `IntegrationFlowRegistration` double check locking is ok for `inputChannel`
because we're assigning an existing object, but `MessagingTemplate` constructs
a new object for which double check locking doesn't work.
In any case, for both these items, the chance of concurrent access is extremely low
and is idempotent anyway, so remove double check locking.
Several inner classes can be static.
Other minor fixes.
