Github user tison1 commented on the issue:
https://github.com/apache/flink/pull/6370
@zentol ok
... close as suggested, would be resolved in #6353
---
Github user zentol commented on the issue:
https://github.com/apache/flink/pull/6370
If another PR introduces race conditions, then these race conditions should
be resolved in that very PR.
---
Github user tison1 commented on the issue:
https://github.com/apache/flink/pull/6370
but the original `ensureConstraints` is wired. For example it calls
`ensureCapacity` twice and the only code path is from `ExecutionJobVertex`
construct `ExecutionVertex` which calls `ensureConstraint
Github user tison1 commented on the issue:
https://github.com/apache/flink/pull/6370
@yanghua AFAIK, yes.
---
Github user yanghua commented on the issue:
https://github.com/apache/flink/pull/6370
@tison1 I think PR #6353 and #6370 has causal relationship, the current
codebase may not trigger this race condition, right?
---
Github user tison1 commented on the issue:
https://github.com/apache/flink/pull/6370
by analyses the use path of this method, we gain little on
`ensureCapacity`, in fact, test fails on #6353 is caused by too many
`ensureCapacity` and then `Array.copyOf` race each other.
---
