Fixes https://github.com/spring-cloud/spring-cloud-stream-binder-aws-kinesis/issues/186
The `DynamoDbLockClient` waits extra `leaseDuration` time in a loop breaking a `tryLock()` contract.
* Fix `DynamoDbLockRegistry.tryLock()` to decrease an actual `additionalTimeToWait` by `leaseDuration`,
so the target `DynamoDbLockClient` when it adds this `leaseDuration` will wait an actual timeout requested
by the `tryLock()` contract.
This way a `tryLock(0)` will definitely return immediately since we really are not interested in blocking
**cherry-pick to 2.5.x**
# Conflicts:
# build.gradle
Fixes https://github.com/spring-cloud/spring-cloud-stream-binder-aws-kinesis/issues/187
The `ShardConsumer` performs a `getShardIterator()` request with some sequence number from checkpointer.
When the shard is closed, it fails with an `InvalidArgumentException` not letting us mark such a consumer a stopped.
* Catch `InvalidArgumentException` on the `getShardIterator()` and see if error is related to a closed shard.
Log such a message and proceed to a `STOP` state for the current `ShardConsumer`.
**Cherry-pick to `2.5.x`**
Related to https://github.com/spring-cloud/spring-cloud-stream-binder-aws-kinesis/issues/180
* Treat non-positive `DynamoDbLockRegistry.heartbeatPeriod` as no heartbeat.
This way locks renewal is a responsibility of the target `DynamoDbLockRegistry` consumer.
For example, the `KinesisMessageDrivenChannelAdapter` does call `tryLock()` in a loop
for locks on shards it is consuming at the moment
* Increase locks loop sleep timeout in the `KinesisMessageDrivenChannelAdapter` to one second
to avoid many requests to DynamoDB
**Cherry-pick to `2.5.x`**
# Conflicts:
# src/main/java/org/springframework/integration/aws/inbound/kinesis/KinesisMessageDrivenChannelAdapter.java
Fixes https://github.com/spring-projects/spring-integration-aws/issues/219
Turns out the `AmazonDynamoDBLockClient` doesn't have a proper logic to
determine correct `lookupTime` and if we want to skip blocking waits,
the item is always treated as not expired because just obtained item from DB
is updated to the current time for its `lookupTime` property
* Remove the logic in the `DynamoDbLockRegistry` setting `withShouldSkipBlockingWait(true)`
**Cherry-pick to `2.5.x`**
# Conflicts:
# src/test/java/org/springframework/integration/aws/lock/DynamoDbLockRegistryTests.java
Fixes https://github.com/spring-projects/spring-integration-aws/issues/218
The `AbstractMessageAttributesHeaderMapper` incorrectly logs only for
SQS service.
* Fix `logger` property to be a `protected` and not `static` to make it
rely on the `getClass()` context
* Fix logging message in the `fromHeaders()` from just `SQS` to `the current AWS service`
**Cherry-pick to `2.5.x`**
Fixes https://github.com/spring-projects/spring-integration-aws/issues/196
* Add support for SNS FIFO message group and deduplication IDs
* Add Javadoc, clean up formatting
* Fix Javadoc formatting
* Add SNS FIFO information to README
* Change XML snippet indentation to tabs
* Code samples throughout the README mix tabs and spaces, but this
snippet was using tabs, so this updates the new lines to match.
* Minor code style clean up
**Cherry-pick to `main`**
Fixes https://github.com/spring-projects/spring-integration-aws/issues/207
* Expose `failOnMissingQueue` flag support for `SqsMessageDrivenChannelAdapter`
* Upgrade to `spring-cloud-aws-2.4.2`
* `fail-on-missing-queue` property support
* `SqsMessageDrivenChannelAdapterParserTests` update
**Cherry-pick to `main`**
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`**
* 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
