[
https://issues.apache.org/jira/browse/FLINK-10570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16658902#comment-16658902
]
Dawid Wysakowicz commented on FLINK-10570:
------------------------------------------
Hi [~Jamalarm], thank you for the report.
The fixed semantic in 1.6 is not the problem here, it still will discard
matches that started before the last event of a match. The problem is that we
haven't released some internal structures in the {{SharedBuffer}}. I've opened
a PR to fix this. It would be helpful if you could try it out and see if this
fixes your problem.
> State grows unbounded when "within" constraint not applied
> ----------------------------------------------------------
>
> Key: FLINK-10570
> URL: https://issues.apache.org/jira/browse/FLINK-10570
> Project: Flink
> Issue Type: Bug
> Components: CEP
> Affects Versions: 1.6.1
> Reporter: Thomas Wozniakowski
> Priority: Major
>
> We have been running some failure monitoring using the CEP library. Simple
> stuff that should probably have been implemented with a window, rather than
> CEP, but we had already set the project up to use CEP elsewhere and it was
> trivial to add this.
> We ran the following pattern (on 1.4.2):
> {code:java}
> begin(PURCHASE_SEQUENCE, AfterMatchSkipStrategy.skipPastLastEvent())
> .subtype(PurchaseEvent.class)
> .times(100)
> {code}
> and then flat selected the responses if the failure ratio was over a certain
> threshold.
> With 1.6.1, the state size of the CEP operator for this pattern grows
> unbounded, and eventually destroys the job with an OOM exception. We have
> many CEP operators in this job but all the rest use a "within" call.
> In 1.4.2, it seems events would be discarded once they were no longer in the
> 100 most recent, now it seems they are held onto indefinitely.
> We have a workaround (we're just going to add a "within" call to force the
> CEP operator to discard old events), but it would be useful if we could have
> the old behaviour back.
> Please let me know if I can provide any more information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
