Fixes https://github.com/spring-projects/spring-integration-aws/issues/205
The `AmazonDynamoDBLockClient.acquireLock()` steps into a busy-wait loop with a sleep timeout.
* Use `AcquireLockOptions.shouldSkipBlockingWait = true` for `tryLock()` without timeout
to have an immediate answer according `tryLock()` contract
* Reset flag to `false` for all other use-cases with `AcquireLockOptions`
**Cherry-pick to `2.5.x`**
It's misleading to see an error for interrupted `KinesisMessageDrivenChannelAdapter.ShardConsumerManager`
on shutdown.
* Move `this.shardConsumerManagerFuture.cancel(true)` in the `doStop()` after `this.active = false;`
* fix(KinesisMessageDrivenChannelAdapter): added logic to not use the NextShardIterator if Manual Checkpointer hasnt reached the last checkpoint
* fix(KinesisMessageDrivenChannel): added logs for getNextShardIterator
* fix(KinesisMessageDrivenChannelAdapter): fixed logic and comments issue
* feat(KinesisMessageDrivenChannelAdapter): implemented integration tests for getNextShardIterator new usecase
* feat(KinesisMessageDrivenChannelAdapter): updated @author
* feat(KinesisMessageDrivenChannelAdapterTests): added author data
Fixes https://github.com/spring-projects/spring-integration-aws/issues/193
Starting with version `2.3` Spring Cloud AWS has been moved
to new Maven coordinates.
* Change `org.springframework.cloud` for SC-AWS to new `io.awspring.cloud`
* Fix imports for new package
* Fix links, coordinates and pacakges in docs
Resolves https://github.com/spring-projects/spring-integration-aws/issues/190
Swallows `ProvisionedThroughputExceededException` while checkpointing
exhausted shards to avoid the `ShardConsumer` from not being marked as
closed and therefore be left in an inconsistent state which will only
throw exceptions as the `shardIterator` would be `null` and the
`ShardConsumer` wouldn't be marked as `CLOSED`.
If we don't have a connection to AWS or our thread is interrupted
for some reason, we should just re-throw that exception as is.
* Only catch a `LockNotGrantedException` which really indicates
that the state of the lock record has been changed.
Therefore we also have to reset local state and try again
Related to https://github.com/spring-cloud/spring-cloud-stream-binder-aws-kinesis/issues/148
If a `DynamoDbLock` has been locked before,
it contains a `lockItem` indicating that we can send a heart-beat
the next tine when we would like to re-lock again instead of calling
regular lock and fail because the lock record exists already.
On the other hand the heart-beat can fail by itself for many reasons
including the case when record in DB was removed somehow.
* Change the `DynamoDbLock.doLock()` logic to catch `sendHeartBeat()`
exception and reset local state to let it to try to lock again with
the regular `tryAcquireLock()` API
Related to https://github.com/spring-cloud/spring-cloud-stream-binder-aws-kinesis/issues/148
The current implementation has a flaw when it uses a distributed lock
for an exclusive access to shard for consuming only once at start up.
Such a behavior cause the problem when we have a network glitch at
runtime, so the lock is broken, but consumer is still active to retry
consumption attempts
* Add `renewLockIfAny()` logic ot the `ShardConsumer`, so we ensure
that we are still a lock holder and don't consume otherwise
* Add `unlockFuture` logic to block the `ShardConsumer.stop()`
until we really got lock unlocked.
Otherwise we end up with the race condition when we are still
stopping, but already ready to start a new consumer for the same
shard
Resolves: https://github.com/spring-projects/spring-integration-aws/issues/183
Exposes `BillingMode` option on the `DynamoDbMetadataStore` and
`DynamoDbLockRegistry`.
Moves the `LockRegistry` table creation to inside
this project as the DynamoDB Lock client doesn't support pay per request
model and that library seems abandoned.
Fixes https://github.com/spring-projects/spring-integration-aws/issues/184
During creating `KclMessageDrivenChannelAdapter`
if `config == null` a default `KinesisClientLibConfiguration` is created
with parameter `leaseCleanupIntervalMillis == 0` which causes an `IllegalArgumentExcpetoin`
when KPL is initialized
* Use default reasonable values for lease clean up intervals.
* Copy respective constants from the `KinesisClientLibConfiguration` into the `KclMessageDrivenChannelAdapter`
since they are `private` over there
