VGalaxies commented on code in PR #3049:
URL: https://github.com/apache/hugegraph/pull/3049#discussion_r3371304518
##########
hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/StandardHugeGraph.java:
##########
@@ -233,6 +234,8 @@ public StandardHugeGraph(HugeConfig config) {
LockUtil.init(this.spaceGraphName());
+ BytesBuffer.initMaxBufferCapacity(
Review Comment:
**Medium: Clean up lock groups when buffer capacity init fails**
`hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/StandardHugeGraph.java:237`
**Evidence**
- `LockUtil.init(this.spaceGraphName())` runs at line 235, then the new
`BytesBuffer.initMaxBufferCapacity(...)` can throw at line 237 on invalid or
conflicting `serializer.buffer_max_capacity`. The constructor cleanup begins
only inside later `try` blocks, so this exception bypasses
`LockUtil.destroy(...)`. `LockManager.create()` throws when a lock group
already exists, so a later retry for the same graph can fail before reaching
the corrected config.
**Impact**
- A single failed graph open caused by this new option can leave
process-wide lock state behind and prevent loading that graph again without
restarting the process.
**Requested fix**
- Move the buffer-capacity initialization before `LockUtil.init(...)`, or
wrap this initialization path so `LockUtil.destroy(this.spaceGraphName())` runs
for any exception after lock initialization.
--
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]
