Two initiators for the same path, same `SmartLifecycleRoleController` and, finally, same `adapter`.
So, one initiator after `yield()` stops the `adapter` and at the same time another starts it.
Since there is no barrier in between events and assertion, we end up with an early "re-granting".
* Add `CountDownLatch yieldBarrier` to `countDown()` after performing second `adapter.isRunning()` assert
* `LeaderEventPublisher` waits for the `yieldBarrier` after the first `OnRevokedEvent`
JIRA: https://jira.spring.io/browse/INT-4167
Since the current `ZkLock.tryLock()` is based on the fact of waiting for **at most 1 second**, that still has some timing issue for test-case, when the network delay may affect our expectation.
* Add `Thread.sleep()` with `while()` to the `ZkLockRegistryTests.testTryLock()` test to spin until successful `tryLock()`
**Cherry-pick to 4.3.x & 4.2.x**
Note: to avoid cherry-pick conflict for `4.2.x` just fully copy/paste the modified test
Conflicts:
spring-integration-zookeeper/src/test/java/org/springframework/integration/zookeeper/lock/ZkLockRegistryTests.java
Resolved.
JIRA: https://jira.spring.io/browse/INT-4143
Gemfire: some fixes and optimization for tests
See https://build.spring.io/browse/INT-AT42SIO-199/
In some places we start `Cache` but doesn't close/destroy it in the end.
That sometimes causes conflicts with the already started GemFire from other tests or wrong state around `BeanFactoryLocator`
* Ensure `Cache` destroy in the end of each test
* In addition destroy `Region` as well to avoid unexpected race conditions, too
* Plus optimize some tests to start `Cache` and `Region` only once per test class, not for each test method
From here I can say that it even would be better to start `Cache`, and therefore whole GemFire, only once per entire Gemfire module test suite.
But that is fully different story.
Remove `forkEvery` from Gemfire module
Allow get a performance improvement for the build.
The `gradlew clean :spring-integration-gemfire:testAll` with existing state is like:
```
Total time: 3 mins 41.375 secs
```
With this fix and without `forkEvery`:
```
Total time: 1 mins 42.699 secs
```
So, 2 min saved time!
Plus fix timeouts in the `PayloadSerializingTransformerParserTests`
Conflicts:
spring-integration-gemfire/src/test/java/org/springframework/integration/gemfire/inbound/CacheListeningMessageProducerTests.java
spring-integration-gemfire/src/test/java/org/springframework/integration/gemfire/outbound/CacheWritingMessageHandlerTests.java
* Change `ZkLockRegistryTests.testTryLock()` to a couple attempts, since there is still some network backpressure involved
https://build.spring.io/browse/INT-AT42SIO-311/
JIRA: https://jira.spring.io/browse/INT-4127
Fixes GH-1913 (https://github.com/spring-projects/spring-integration/issues/1913)
The current `tryLock()` implementation with the `0` timeout to wait for underlying `InterProcessMutex` answer makes this function almost fully impossible
* Fix `ZkLock.tryLock()` to delegate with the `tryLock(1, TimeUnit.SECONDS)` to give some time window chance for network communication.
It isn't ideal for the `tryLock()` contract, but at least it is better then don't let the feature to work at all.
**Cherry-pick to 4.3.x & 4.2.x**
https://build.spring.io/browse/INT-AT42SIO-253/
```
java.lang.AssertionError: Should have been able to lock with zookeeper server restarted!
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.springframework.integration.zookeeper.lock.ZkLockRegistryTests.voidLockFailsWhenServerDown(ZkLockRegistryTests.java:339)
```
When we do `testingServer.restart();` we should give more time to let it started on background, therefore increase the next `lock2.tryLock()` to 10 seconds.
**Cherry-pick to 4.3.x and 4.2.x**
(cherry picked from commit 6ffdd5e)
(cherry picked from commit 0d7e3f7)
JIRA: https://jira.spring.io/browse/INT-4087
Fixes GH-1863 (https://github.com/spring-projects/spring-integration/issues/1863)
If ZK Client loses the connection to ensemble, it tries to reconnect on the next operation and does that exactly for the `connectionTimeoutMs` and provided `RetryPolicy`.
According to the `Lock.tryLock(long time, TimeUnit unit)` contract we can wait for the lock only during provided `timeout`.
* Introduce `mutexTaskExecutor` and perform `ZK.forPath()` command in the separate `Thread` and wait for the `Future` during provided timeout.
* Perform `mutex.acquire()` only after successful `Future` result and only for the remained timeout.
**Cherry-pick to 4.2.x**
Add `setMutexTaskExecutor()`
Fix Checkstyle typo
Javadoc
Conflicts:
spring-integration-zookeeper/src/main/java/org/springframework/integration/zookeeper/lock/ZookeeperLockRegistry.java
Resolved.
JIRA: https://jira.spring.io/browse/INT-3916
The `JpaOutboundGatewayFactoryBean` used CTOR injection for the `JpaExecutor`.
That one, in turn, uses CTOR injection for the `EntityManagerFactory`.
Such a dependency may cause the `early bean instantiating` in case of `AbstractAutowireCapableBeanFactory.getSingletonFactoryBeanForTypeCheck()`.
And we end up with the `BeanCurrentlyInCreationException`.
Therefore no one `FactoryBean` should use CTOR injection if there is a potential hierarchical dependency.
NOTE: there is no tests on the matter, since we don't change the components behavior.
The `JPA` sample application will be changed to the Boot to track this fix.
**Cherry-pick to 4.2.x**
Address PR comments and fix other `FactoryBean`s for the same issue, when it is reasonable
Polishing
Address PR comments
Make setter `setSockJsTaskScheduler` as `public`
Conflicts:
spring-integration-websocket/src/main/java/org/springframework/integration/websocket/config/WebSocketIntegrationConfigurationInitializer.java
spring-integration-xmpp/src/main/java/org/springframework/integration/xmpp/config/XmppConnectionFactoryBean.java
spring-integration-xmpp/src/test/java/org/springframework/integration/xmpp/config/XmppConnectionFactoryBeanTests-context.xml
spring-integration-xmpp/src/test/java/org/springframework/integration/xmpp/config/XmppConnectionFactoryBeanTests.java
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-3781
- Add mechanisms to set status code on an inbound gateway timeout.
- Send a message to the error channel if configured.
Polishing - Add failedMessage to MTE
Fix Schema Docs; Timeout Detection on Error Flow
Add Zookeeper Leadership Logs
Fix typo in the `SmartLifecycleRoleController`
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-3617
Start/stop `SmartLifecyle` beans with leader election/revocation.
ZK Namespace Support
Add Annotation Support
INT-3617: Polishing
Add `SmartLifecycle` to listener parser.
INT-3617: Polishing; PR Comments
Revert SmartLifecycleRoleController
Remove reflection.
Remove Dependence on spring-cloud-cluster
Temporarily move the relevant classes here.
Polishing; PR Comments and Fix Test
Test was incorrectly stopping the LeaderInitiator before it was elected.
Set auto-startup="false" in the i-c-a so we wait for its start before
stopping the LeaderInitiator.
Fix JavaDocs
JIRA: https://jira.spring.io/browse/INT-3616
Zookeeper implementation of `LockRegistry`, for example to support
clustered aggregators (when using external message group stores).
INT-3616: Polishing; PR Comments
JIRA: https://jira.spring.io/browse/INT-3691
- create new core interfaces `ListenableMetadataStore` and `MessageStoreListener`;
- create new module `spring-integration-zookeeper`;
- add `ZookeeperMetadataStore` implementation
Polishing
Polishing
- moved classes into core/test where necessary, including conversion methods
- properly renamed `MetadataStoreListenerAdapter`
