Hi Dawid,
Just back in the office. The platform we run on recently announced Flink
1.6.0 support, so we upgraded and haven't seen this problem arise again
yet! We believe it could have been the `equals` method falsely matching
different records in rare instances, though the upgrade to Flink 1.6.0
Hi Austin,
Could you provide jobmanagers and taksmanagers logs for a failed run?
The exception you've posted is thrown during processing messages, rather
than during restoring, but you said it failed to restore checkpoint, how
come it processes messages? Could you also describe exact conditions
Hi Dawid,
Thank you for your reply. I'm out for the next few days, so I hope you
don't mind me cc'ing my team in here. We all really appreciate you and the
rest of the people monitoring the mailing list.
We've only seen this SharedBuffer problem in production, after sending
around 20 GB of data
Hi Austin,
Could you elaborate a bit more what do you mean by "after a checkpoint
fails", what is the reason why checkpoint fails? Would it be possible
for you to prepare some reproducible example for that problem? Finally,
I would also recommend trying out Flink 1.6.x, as we reworked the
Following up, we are using Flink 1.5.0 and Flink-CEP 2.11.
Thanks,
Austin
On Tue, Oct 30, 2018 at 3:58 PM Austin Cawley-Edwards <
austin.caw...@gmail.com> wrote:
> Hi there,
>
>
> We have a streaming application that uses CEP processing but are getting this
> error fairly frequently after a
Hi there,
We have a streaming application that uses CEP processing but are
getting this error fairly frequently after a checkpoint fails, though
not sure if it is related. We have implemented both `hashCode` and
`equals()` using `Objects.hash(...properties)` and basic equality,
respectively.
