Flink internal threading model design?

Is this written up somewhere?

Having some difficulty understanding the intended design. Want to understand the assumptions I should make about when certain functions will be called (for example JDBCOutputFormat open vs flush vs writeRecord vs close) and whether this will always be from the same thread or some other thread, or whether they might be called concurrently, in order to verify the correctness of the code.

What guarantees are there?

Does a certain reference need a volatile or even a synchronisation or not.

What's the design for threading?

If the intended design is not written down then we have to infer it from the code and we might come to different conclusions and thus bugs and leaks.

It's really hard writing good MT code and a strong design is necessary to provide a framework for the code.

Some info here https://flink.apache.org/contributing/code-style-and-quality-common.html#concurrency-and-threading , but this isn't a design and doesn't say how it's meant to work.

==

Another, example. When I see code like this ...

FileOutputFormat

   public void close() throws IOException {
        final FSDataOutputStream s = this.stream;
        if (s != null) {
            this.stream = null;
            s.close();
        }
    }

My feeling is that someone wasn't sure either what the right approach was. I can only guess that the author was concerned that someone else was going to call the function concurrently, or mess with the class state by some other means. And, if that were true then would this code even be MT safe - who knows? Ought there be a volatile in there or a plain old sync or perhaps none of the caution is needed at all (framework guarantees preventing the need).

I see a lot of code in the project that is similarly uncertain and inconsistent.

Hmm?