[GitHub] flink issue #3745: [FLINK-6341]Don't let JM fall into infinite loop

2017-04-28 Thread tillrohrmann
Github user tillrohrmann commented on the issue: https://github.com/apache/flink/pull/3745 Thanks for your contribution @WangTaoTheTonic. Changes look good to me. Merging your PR. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub a

[GitHub] flink issue #3745: [FLINK-6341]Don't let JM fall into infinite loop

2017-04-24 Thread WangTaoTheTonic
Github user WangTaoTheTonic commented on the issue: https://github.com/apache/flink/pull/3745 I see. Connection ID is added, please check if it's ok :) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does

[GitHub] flink issue #3745: [FLINK-6341]Don't let JM fall into infinite loop

2017-04-24 Thread tillrohrmann
Github user tillrohrmann commented on the issue: https://github.com/apache/flink/pull/3745 It is a problem because, the `currentResourceManager` is not volatile. Thus, you might miss some state changes in the future callback because of a cached value. Moreover, accessing mutable actor

[GitHub] flink issue #3745: [FLINK-6341]Don't let JM fall into infinite loop

2017-04-23 Thread WangTaoTheTonic
Github user WangTaoTheTonic commented on the issue: https://github.com/apache/flink/pull/3745 @tillrohrmann What problem it will bring if we access `currentResourceManager` from another thread? It is a variable in JobManager and can be shared across multi threads, right? The new added

[GitHub] flink issue #3745: [FLINK-6341]Don't let JM fall into infinite loop

2017-04-20 Thread tillrohrmann
Github user tillrohrmann commented on the issue: https://github.com/apache/flink/pull/3745 Thanks for spotting the problem @WangTaoTheTonic. This is important to fix. I think we cannot solve the problem as you've done it, because you access actor state from outside of the acto