Specify a shard iterator using the
ShardIterator parameter. The shard
iterator specifies the position in the shard from which you want to start reading
data records sequentially. If there are no records available in the portion of the
shard that the iterator points to, GetRecords returns an empty list. Note that
it might take multiple calls to get to a portion of the shard that contains records.
You can scale by provisioning multiple shards. Your application should have one thread
per shard, each reading continuously from its stream. To read from a stream continually,
call GetRecords in a loop. Use GetShardIterator to get the shard iterator
to specify in the first GetRecords call. GetRecords returns a new shard
NextShardIterator. Specify the shard iterator returned in
NextShardIterator in subsequent calls to GetRecords. Note that
if the shard has been closed, the shard iterator can't return more data and GetRecords
NextShardIterator. You can terminate the
loop when the shard is closed, or when the shard iterator reaches the record with
the sequence number or other attribute that marks it as the last record to process.
Each data record can be up to 1 MB in size, and each shard can read up to 2 MB per
second. You can ensure that your calls don't exceed the maximum supported size or
throughput by using the
Limit parameter to specify the maximum number
of records that GetRecords can return. Consider your average record size when
determining this limit.
The size of the data returned by GetRecords will vary depending on the utilization
of the shard. The maximum size of data that GetRecords can return is 10 MB.
If a call returns this amount of data, subsequent calls made within the next 5 seconds
ProvisionedThroughputExceededException. If there is insufficient
provisioned throughput on the shard, subsequent calls made within the next 1 second
ProvisionedThroughputExceededException. Note that GetRecords
won't return any data when it throws an exception. For this reason, we recommend that
you wait one second between calls to GetRecords; however, it's possible that
the application will get exceptions for longer than 1 second.
To detect whether the application is falling behind in processing, you can use the
MillisBehindLatest response attribute. You can also monitor the stream
using CloudWatch metrics (see Monitoring
Amazon Kinesis in the Amazon Kinesis Developer Guide).
Each Amazon Kinesis record includes a value,
that is set when an Amazon Kinesis stream successfully receives and stores a record.
This is commonly referred to as a server-side timestamp, which is different than a
client-side timestamp, where the timestamp is set when a data producer creates or
sends the record to a stream. The timestamp has millisecond precision. There are no
guarantees about the timestamp accuracy, or that the timestamp is always increasing.
For example, records in a shard or across a stream might have timestamps that are
out of order.
Version: (assembly version)
public virtual GetRecordsResponse GetRecords( GetRecordsRequest request )
Container for the necessary parameters to execute the GetRecords service method.
|ExpiredIteratorException||The provided iterator exceeds the maximum age allowed.|
|InvalidArgumentException||A specified parameter exceeds its restrictions, is not supported, or can't be used. For more information, see the returned message.|
|ProvisionedThroughputExceededException||The request rate is too high, or the requested data is too large for the available throughput. Reduce the frequency or size of your requests. For more information, see Error Retries and Exponential Backoff in AWS in the AWS General Reference.|
|ResourceNotFoundException||The requested resource could not be found. The stream might not be specified correctly, or it might not be in the ACTIVE state if the operation requires it.|
Supported in: 4.5, 4.0, 3.5