Hi Steffen,
Thanks for bringing up the discussion!
I think the reason why SHARD_GETRECORDS_INTERVAL_MILLIS was defaulted to 0 in
the first place was because we didn’t want false impressions that the there was
some latency introduced in Flink with the default settings.
To this end, I’m leaning t
Thanks for filing the JIRA!
Would you also be up to open a PR to for the change? That would be very very
helpful :)
Cheers,
Gordon
On 24 April 2017 at 3:27:48 AM, Steffen Hausmann (stef...@hausmann-family.de)
wrote:
Hi Gordon,
thanks for looking into this and sorry it took me so long to fi
Hi Gordon,
thanks for looking into this and sorry it took me so long to file the
issue: https://issues.apache.org/jira/browse/FLINK-6365.
Really appreciate your contributions for the Kinesis connector!
Cheers,
Steffen
On 22/03/2017 20:21, Tzu-Li (Gordon) Tai wrote:
Hi Steffan,
I have to ad
Hi Steffan,
I have to admit that I didn’t put too much thoughts in the default values for
the Kinesis consumer.
I’d say it would be reasonable to change the default values to follow KCL’s
settings. Could you file a JIRA for this?
In general, we might want to reconsider all the default values f
Hi there,
I recently ran into problems with a Flink job running on an EMR cluster
consuming events from a Kinesis stream receiving roughly 15k
event/second. Although the EMR cluster was substantially scaled and CPU
utilization and system load were well below any alarming threshold, the
proces
