Fixesspring-projects/spring-integration-aws#84Fixesspring-cloud/spring-cloud-stream-binder-aws-kinesis#38Fixesspring-cloud/spring-cloud-stream-binder-aws-kinesis#36
Even if AWS Client has some reconnect and retry mechanism, it can be
exhausted and no connection error is rethrown to the `KinesisMessageDrivenChannelAdapter`
anyway.
On the other hand the error can be thrown from the record processor -
the flow on the `outputChannel`.
* log the exception around AWS Client calls and let background process
to restore/retry
* log the exception around message to send to let the processor to move
to the next record or perform the next task
* null the current `task` in the `ShardConsumer` in the `finally` block
to avoid hanging the thread without ability to moving to some other state
without end-user interaction
* When perform the `batch` checkpoint, check the result and if it is
negative, consider such a situation as processed and skip records from
sending downstream
* Upgrade dependencies
* Use Log4J2 for tests logging
Fixes GH-22 (https://github.com/spring-projects/spring-integration-aws/issues/22)
Rework logic to the `dispatching` and tasks
* Add `LimitExceededException` and configurable retry logic for the `describeStream`
* Skip `CLOSED` shards which has been read before according stored `checkpoint`. Will be useful for `after resharding` algorithm
* Add `adapt to resharding` logic
* Add `KinesisMessageDrivenChannelAdapterTests` based on mocks
* Add Thread Affinity for `ShardConsumer`s via `concurrency` option
* Introduce `concurrency` option and `ConsumerInvoker`.
`ShardConsumer`s are now distributed between `ConsumerInvoker`s if `concurrency > 0`
`ConsumerInvoker`s are scheduled to the `ConsumerExecutor` as a `isLongLived` tasks
The concurrency is adjusted if there are no more `ShardConsumer`s to process (`STOP` state because of closed shard).
At the same time newly populated `ShardConsumer`s (e.g. after resharding) is distributed evenly between existing `ConsumerExecutor`s if `maxConcurrency` is exceeded.
Otherwise fresh `ConsumerExecutor` is started for new `ShardConsumer`
JIRA: https://jira.spring.io/browse/INTEXT-51,
https://jira.spring.io/browse/INTEXT-194,
https://jira.spring.io/browse/INTEXT-199
* Add S3 Inbound Channel Adapter fully based on the `AbstractInboundFileSynchronizer`,
`AbstractInboundFileSynchronizingMessageSource` implementation.
* Provide the standard SI `RemoteFileTemplate` and `SessionFactory` abstractions implementations.
* Upgrade to Gradle-2.12
* Provide Namespace support
* Ensure everything with tests
* Remove legacy, redundant implementation, infrastructure code for it and test-cases.
Everything in favor of the new implementation.
JIRA: https://jira.spring.io/browse/INTEXT-197
* Modified the `org/springframework/integration/aws/config/xml/spring-integration-aws-1.0.xsd` to add `channelAdapterAttributes` to expose
`phase` attribute in `s3 outbound adapter`.
* Modified `AmazonS3OutboundChannelAdapterParserTests` - Added Unit Test Class to test the `channelAdapterAttributes`.
* Modified `s3-valid-outbound-cases.xml` - Added separate definition `withChannelAdapterAttributes` for phase attribute.
Polishing according PR comments
JIRA: https://jira.spring.io/browse/INTEXT-187
* Modified the `spring-integration-aws-1.0.xsd` to accommodate `request-handler-advice-chain`
in s3 outbound adapter after feedback.
* Modified `AmazonS3OutboundChannelAdapterParserTests` - Added Unit Test Class with Mock Object to test the request handler chain.
* Modified `s3-valid-outbound-cases.xml` - Added separate definition withHandlerChain with mock Operations.
JIRA: https://jira.spring.io/browse/INTEXT-136
* Add `spring-cloud-aws` dependencies
* Remove all SES stuff, since Spring Cloud AWS provides implementations for `org.springframework.mail.MailSender`
