SebastianGruza commented on code in PR #3220:
URL: https://github.com/apache/hugegraph/pull/3220#discussion_r4053317864
##########
hugegraph-server/hugegraph-api/src/main/java/org/apache/hugegraph/core/GraphManager.java:
##########
@@ -727,19 +727,38 @@ public void destroy() {
}
private void initMetaManager(HugeConfig conf) {
+ if (conf.get(ServerOptions.META_USE_CA)) {
+ this.ca = new K8sDriver.CA(conf.get(ServerOptions.META_CA),
+ conf.get(ServerOptions.META_CLIENT_CA),
+
conf.get(ServerOptions.META_CLIENT_KEY));
+ }
+ connectMetaManager(conf);
+ }
+
+ /**
+ * Connect the MetaManager under the cluster name of rest-server.properties
+ * (option 'cluster'). Idempotent, and it fails when the MetaManager was
+ * connected earlier under another name: the meta keys are prefixed with
+ * the cluster, so the server would otherwise read an empty tree. Called
+ * from HugeGraphServer before any graph is opened, because opening an
+ * hstore graph connects the MetaManager with the graph's 'pd.cluster'
+ * (default 'hg') if nothing connected it yet.
+ */
+ public static void connectMetaManager(HugeConfig conf) {
+ String cluster = conf.get(ServerOptions.CLUSTER);
String endpoints = conf.get(ServerOptions.PD_PEERS);
- boolean useCa = conf.get(ServerOptions.META_USE_CA);
String ca = null;
String clientCa = null;
String clientKey = null;
- if (useCa) {
+ if (conf.get(ServerOptions.META_USE_CA)) {
ca = conf.get(ServerOptions.META_CA);
clientCa = conf.get(ServerOptions.META_CLIENT_CA);
clientKey = conf.get(ServerOptions.META_CLIENT_KEY);
- this.ca = new K8sDriver.CA(ca, clientCa, clientKey);
}
- this.metaManager.connect(this.cluster, MetaManager.MetaDriverType.PD,
- ca, clientCa, clientKey, endpoints);
+ MetaManager manager = MetaManager.instance();
+ manager.connect(cluster, MetaManager.MetaDriverType.PD,
+ ca, clientCa, clientKey, endpoints);
+ manager.ensureCluster(cluster);
Review Comment:
Thanks for tracing this path; I checked it two ways and would like to be
precise, because in the described form it does not occur. `ensureCluster()` is
called only from `connectMetaManager()`, which has two callers:
`HugeGraphServer` (explicitly behind the `usePD` guard) and
`GraphManager.initMetaManager()`. `initMetaManager()` has a single caller,
`loadMetaFromPD()` (line 376), and `loadMetaFromPD()` runs only in the
constructor under `if (PDExist)` (lines 271-274), i.e. only with `usePD=true`.
With `usePD=false` the server never reaches `ensureCluster` at all;
`StandardHugeGraph` binds `pd.cluster` and that is the end of it, exactly as in
1.7.0.
Measured on the lab (1 PD + 3 stores, data written by the official 1.7.0
release, a build of this head), with `usePD` and `pd.peers` removed from
`rest-server.properties`: with the default `pd.cluster` the server starts, the
graph opens, 0 property keys (the data lives under `hg-test`, which is
expected), and zero `ensureCluster`/`IllegalStateException` lines in the log;
with `pd.cluster=hg-test` in the graph file the server starts and sees all 13
keys, log equally clean. With `usePD=true` restored: 13 keys and `Meta cluster
bound to 'hg-test'`. Log:
`results/upgrade-170-to-master/logs/usepd-false-round2.txt` in the validation
repo.
I added the gate anyway in 8e914e6f, since it is cheap and protects against
a future caller: `connectMetaManager()` returns without binding or checking
when `usePD=false`, with a comment that the graph-level binding is then the
only one and no server-side check may apply to it. Two tests:
`testUsePdFalseLeavesTheGraphLevelBindingAlone` (a graph bound `hg`, calling
the helper with `usePD=false` does not throw and the cluster stays `hg`) and
`testGraphManagerStartupWithUsePdFalseKeepsTheGraphBinding` (a `GraphManager`
constructed with `usePD=false` after such a binding completes without an
exception, cluster still `hg`). `MetaManagerClusterTest` 9/9.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
