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
hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/StandardHugeGraph.java:237
- Clean up lock groups when buffer capacity init fails
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]
