imbajin commented on code in PR #3049:
URL: https://github.com/apache/hugegraph/pull/3049#discussion_r3375002901
##########
hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/StandardHugeGraph.java:
##########
@@ -231,15 +232,19 @@ public StandardHugeGraph(HugeConfig config) {
this.readMode = GraphReadMode.OLTP_ONLY;
this.schedulerType = config.get(CoreOptions.SCHEDULER_TYPE);
- LockUtil.init(this.spaceGraphName());
-
+ // Init process-wide static configs before lock, so that validation
+ // failures won't leave stale lock groups in LockManager.
+ BytesBuffer.initMaxBufferCapacity(
Review Comment:
‼️ **Keep the process-wide cap from conflicting with default graph configs**
Evidence: `GraphManager` loads every file under `conf/graphs` in one JVM,
and each `StandardHugeGraph` calls
`BytesBuffer.initMaxBufferCapacity(config.get(...))`. With this option stored
as a graph option, the first graph that sets
`serializer.buffer_max_capacity=268435456` freezes the static cap, then any
later graph that omits the option still passes the default `134217728` and
fails with the new conflicting-value check.
Impact: enabling this option for one graph can prevent a normal multi-graph
server from starting unrelated graphs, even though a process-wide setting
should be shared by the process.
Requested fix: move the source to server-wide config, or treat an
unset/default graph value as inheriting the already-initialized process value,
and add a `GraphManager`/`MultiGraphsTest` case covering one custom graph plus
one default graph.
--
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]
