[FLINK-23020][table-planner] Use FlinkDefaultRelMetadataProvider when accessing FlinkRelMetadataQuery from a different thread

[swtwsk]

What is the purpose of the change

FlinkRelMetadataQuery depends on Apache Calcite RelMetadataQuery's THREAD_PROVIDERS field, which is a ThreadLocal. FlinkRelOptClusterFactory (implicitly) sets THREAD_PROVIDERS to the constant FlinkDefaultRelMetadataProvider instance. However, due to the fact that THREAD_PROVIDERS is an instance of a ThreadLocal, when a different thread tries to access RelMetadataQuery::instance, NullPointerException gets thrown. This change ensures that RelMetadataQuery has a reference to FlinkDefaultRelMetadataProvider regardless of the thread it gets accessed by.

Brief change log

• Use FlinkDefaultRelMetadataProvider when accessing FlinkRelMetadataQuery from a different thread.

Verifying this change

This change added tests and can be verified as follows:

• Added multithreaded test FlinkRelMetadataQueryThreadingTest
• Manually verified the change by running a simple PyFlink job inside Jupyter notebook, interrupting kernel execution (sending SIGINT to py4j/Flink instance), and running the job again (basically running the example described in the JIRA ticket)

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changed class annotated with @Public(Evolving): no
• The serializers: no
• The runtime per-record code paths (performance sensitive): don't know
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? no
• If yes, how is the feature documented? not applicable

[flinkbot]

CI report:

• 8b15eb8 Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[fapaul]

@snuyanzin do you have time to help with this PR? In general, I am missing a lot of nuances in Flink's table API, so would be good if someone with more knowledge can take a look at this change.

From my side, moving towards making the TableEnvironment thread-safe is a good idea, but I can easily miss something here.

cc @twalthr

[snuyanzin]

I read through the jira issue and from what I see there I feel a lack of test reproducing jira issue. Can we have such here to be sure that this is the actual root cause?

I'm asking since i was even fail to see any logs/traces in issue. So no idea what's NPE is discussing there