curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-720296877
Hey @pnowojski , I rebased it again.
0a8a44c Azure: SUCCESS
https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=8743=results
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-718354004
Hey @tillrohrmann , thanks for bringing this up. We've nowhere explicitly
explained why to bring a new ResultPartitionType, so I think here is a good
place to discuss the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-718354004
Hey @tillrohrmann , thanks for bringing this up. We've nowhere explicitly
explained why to bring a new ResultPartitionType, so I think here is a good
place to discuss the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-718354004
Hey @tillrohrmann , thanks for bringing this up. We've nowhere explicitly
explained why to bring a new ResultPartitionType, so I think here is a good
place to discuss the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-718354004
Hey @tillrohrmann , thanks for bringing this up. We've nowhere explicitly
explained why to bring a new ResultPartitionType, so I think here is a good
place to discuss the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-718354004
Hey @tillrohrmann , thanks for bringing this up. We've nowhere explicitly
explained why to bring a new ResultPartitionType, so I think here is a good
place to discuss the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-718354004
Hey @tillrohrmann , thanks for bringing this up. We've nowhere explicitly
explained why to bring a new ResultPartitionType, so I think here is a good
place to discuss the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-718354004
Hey @tillrohrmann , thanks for bringing this up. We've nowhere explicitly
explained why to bring a new ResultPartitionType, so I think here is a good
place to discuss the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-718354004
Hey @tillrohrmann , thanks for bringing this up. We've nowhere explicitly
explained why to bring a new ResultPartitionType, so I think here is a good
place to discuss the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-717237157
Synced up offline, I think we might have a slightly different understanding
of "what the problem is"
1. In any case, there won't be a "correctness" issue, because
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-716973831
Hey @rkhachatryan and @pnowojski , thanks for the response.
> We realized that if we check view reference in subpartition (or null out
view.parent) then the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-716973831
Hey @rkhachatryan and @pnowojski , thanks for the response.
> We realized that if we check view reference in subpartition (or null out
view.parent) then the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-716973831
Hey @rkhachatryan and @pnowojski , thanks for the response.
> We realized that if we check view reference in subpartition (or null out
view.parent) then the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-716973831
Hey @rkhachatryan and @pnowojski , thanks for the response.
> We realized that if we check view reference in subpartition (or null out
view.parent) then the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-716973831
Hey @rkhachatryan and @pnowojski , thanks for the response.
> We realized that if we check view reference in subpartition (or null out
view.parent) then the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-716973831
Hey @rkhachatryan and @pnowojski , thanks for the response.
> We realized that if we check view reference in subpartition (or null out
view.parent) then the
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714599452
Thanks, @rkhachatryan for clarifying the problem!
I agree there is a problem if a downstream task continuously fails multiple
times, or an orphan task execution may
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714599452
Thanks, @rkhachatryan for clarifying the problem!
I agree there is a problem if a downstream task continuously fails multiple
times, or an orphan task execution may
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714211577
> * Visilibity in normal case: none of the felds written in `releaseView`
are `volatile`. So in normal case (`t1:release` then `t2:createReadView`) `t2`
can see some
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714211577
> * Visilibity in normal case: none of the felds written in `releaseView`
are `volatile`. So in normal case (`t1:release` then `t2:createReadView`) `t2`
can see some
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714211577
> * Visilibity in normal case: none of the felds written in `releaseView`
are `volatile`. So in normal case (`t1:release` then `t2:createReadView`) `t2`
can see some
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714211577
> * Visilibity in normal case: none of the felds written in `releaseView`
are `volatile`. So in normal case (`t1:release` then `t2:createReadView`) `t2`
can see some
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714211577
> * Visilibity in normal case: none of the felds written in `releaseView`
are `volatile`. So in normal case (`t1:release` then `t2:createReadView`) `t2`
can see some
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714211577
> * Visilibity in normal case: none of the felds written in `releaseView`
are `volatile`. So in normal case (`t1:release` then `t2:createReadView`) `t2`
can see some
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714211577
> * Visilibity in normal case: none of the felds written in `releaseView`
are `volatile`. So in normal case (`t1:release` then `t2:createReadView`) `t2`
can see some
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714211577
> * Visilibity in normal case: none of the felds written in `releaseView`
are `volatile`. So in normal case (`t1:release` then `t2:createReadView`) `t2`
can see some
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714211577
> * Visilibity in normal case: none of the felds written in `releaseView`
are `volatile`. So in normal case (`t1:release` then `t2:createReadView`) `t2`
can see some
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714211577
> * Visilibity in normal case: none of the felds written in `releaseView`
are `volatile`. So in normal case (`t1:release` then `t2:createReadView`) `t2`
can see some
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714211577
> * Visilibity in normal case: none of the felds written in `releaseView`
are `volatile`. So in normal case (`t1:release` then `t2:createReadView`) `t2`
can see some
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-714211577
> * Visilibity in normal case: none of the felds written in `releaseView`
are `volatile`. So in normal case (`t1:release` then `t2:createReadView`) `t2`
can see some
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-713341581
Thanks @rkhachatryan so much for the great question on how different threads
access the same view (in other words, threading model in netty + task thread
interaction on
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-713341581
Thanks @rkhachatryan so much for the great question on how different threads
access the same view (in other words, threading model in netty + task thread
interaction on
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-713341581
Thanks @rkhachatryan so much for the great question on how different threads
access the same view (in other words, threading model in netty + task thread
interaction on
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-713341581
Thanks @rkhachatryan so much for the great question on how different threads
access the same view (in other words, threading model in netty + task thread
interaction on
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-713341581
Thanks @rkhachatryan so much for the great question on how different threads
access the same view (in other words, threading model in netty + task thread
interaction on
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-713341581
Thanks @rkhachatryan so much for the great question on how different threads
access the same view (in other words, threading model in netty + task thread
interaction on
curcur edited a comment on pull request #13648:
URL: https://github.com/apache/flink/pull/13648#issuecomment-713341581
Thanks @rkhachatryan so much for the great question on how different threads
access the same view (in other words, threading model in netty + task thread
interaction on
37 matches
Mail list logo
