imbajin commented on code in PR #3049:
URL: https://github.com/apache/hugegraph/pull/3049#discussion_r3360146743
##########
hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/backend/serializer/BytesBuffer.java:
##########
@@ -174,13 +192,15 @@ private void require(int size) {
}
// Extra capacity as buffer
- int newCapacity = size + this.buffer.limit() + DEFAULT_CAPACITY;
- if (newCapacity > MAX_BUFFER_CAPACITY) {
+ long newCapacity = (long) size + this.buffer.limit() +
Review Comment:
⚠️ Non-blocking, but this checks the padded growth target against the
configured max, not the actual required size. For example, with `max=128`, a
full 64-byte buffer rejects a 1-byte write because `64 + 1 + DEFAULT_CAPACITY
== 129`, even though the final content size would only be 65. Consider checking
`position + size > maxCapacity` for rejection, then allocating `min(position +
size + DEFAULT_CAPACITY, maxCapacity)` when the write itself still fits.
##########
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.setMaxBufferCapacity(
Review Comment:
‼️ I think a process-wide buffer limit is the right scope here, because
`BytesBuffer` is a static low-level utility and many call sites do not carry
graph context. The issue is that this currently behaves like a graph-level
config that each `StandardHugeGraph` constructor can overwrite, so the last
opened graph silently changes the limit for all graphs in the same JVM. Please
make the process-wide semantic explicit: initialize the value once, document
`serializer.buffer_max_capacity` as JVM/process-wide, and reject conflicting
values when another graph is opened with a different setting. A focused
multi-graph test for this conflict/last-opened behavior would be enough; no
need to refactor the whole serializer path into per-graph state for this PR.
--
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]
