Vladimir Pchelko
Vladimir Pchelko
This is the necessary option. For now I am now creating a dynamoDB table and adding the necessary values for each shard (lease)
I struggled with KCL for a long time - this is a very unstable API - reacts extremely badly to resharding - many shards simply stop being processed (only restarting...
maybe this https://github.com/awslabs/amazon-kinesis-producer/issues/48 Too large value of OutstandingRecordsCount causes native part (see C++ code) of KPL to consume too much CPU time. It seems that this "bug" has existed since...
The value of RecordMaxBufferedTime is too high. When you increase the number of shards - you proportionally increase the number of records - that KPL waits for the buffer to...
No, just use java kinesis client and amazon-kinesis-aggregator for purposes of better behavior control. Also don't use KPL in AWS lambdas since KPL starts a native process!!! - this is...
Check KPL Sample how to handle **ListenableFuture** properly https://github.com/awslabs/amazon-kinesis-producer/blob/master/java/amazon-kinesis-producer-sample/src/com/amazonaws/services/kinesis/producer/sample/SampleProducer.java You awaiting for **5 seconds** when default record TTL is **30 seconds**. https://github.com/awslabs/amazon-kinesis-producer/blob/2b2a38d48a2df94189188c98ba39f1310d896836/java/amazon-kinesis-producer/src/main/java/com/amazonaws/services/kinesis/producer/KinesisProducerConfiguration.java#L781
Using Lombock is sabotage - it greatly interferes with navigation through the code as well as debugging ... "invisible" getters and setters, as well as constructors! For now many AWS...
Reproduced this bug with hadoop-* 3.3.5 and aws-java-sdk 1.12.310 Fixed by rolling back to versions 3.1.0 (hadoop-*) and 1.1.655 (aws-java-sdk-*) for me this piece of code cause the problem ...
BUMP