Got that, thanks. I'll try
On Mon, Oct 18, 2021 at 11:50 AM Arvid Heise wrote:
> If you submit a fat jar to Flink, it contains the Kinesis connector. Dawid
> was suggesting to also add the SequenceNumber to your src with the original
> package name such that you effectively overwrite the class o
If you submit a fat jar to Flink, it contains the Kinesis connector. Dawid
was suggesting to also add the SequenceNumber to your src with the original
package name such that you effectively overwrite the class of Kinesis while
creating the fat jar (there should be warning and you should double-chec
Thanks for answering.
Not sure I understood the hack suggestion. If I copy SequenceNumber over to
my job, how the original Flink Kinesis lib will use that class? It's fixed
on a specific package (in this case
org.apache.flink.streaming.connectors.kinesis.model. Unless, you meant to
somehow hack th
Hey Ori,
As for the SequenceNumber issue, I'd say yes, it can be seen as a bug.
In the current state one can not use kinesis consumer with the
pipeline.generic-types=false. The problem is because we use the
TypeInformation.of(SequenceNumber.class) method, which will in this case
always fallback to
I'd appreciate if someone could advice on this issue.
Thanks
On Tue, Oct 12, 2021 at 4:25 PM Ori Popowski wrote:
> Hi,
>
> I have a large backpressure in a somewhat simple Flink application in
> Scala. Using Flink version 1.12.1.
>
> To find the source of the problem, I want to eliminate all cl
Hi,
I have a large backpressure in a somewhat simple Flink application in
Scala. Using Flink version 1.12.1.
To find the source of the problem, I want to eliminate all classes with
generic serialization, so I set
pipeline.generic-types=false
in order to spot those classes and write a serializer
