imbajin commented on code in PR #3049:
URL: https://github.com/apache/hugegraph/pull/3049#discussion_r3402205068
##########
hugegraph-server/hugegraph-core/src/main/java/org/apache/hugegraph/backend/serializer/BytesBuffer.java:
##########
@@ -122,6 +126,43 @@ public static BytesBuffer wrap(byte[] array, int offset,
int length) {
return new BytesBuffer(ByteBuffer.wrap(array, offset, length));
}
+ public static int maxBufferCapacity() {
+ Integer capacity = maxBufferCapacity;
+ return capacity != null ? capacity : MAX_BUFFER_CAPACITY;
+ }
+
+ public static synchronized void initMaxBufferCapacity(int capacity) {
+ initMaxBufferCapacity(capacity, true);
+ }
+
+ public static synchronized void initMaxBufferCapacity(int capacity,
+ boolean explicit) {
+ E.checkArgument(capacity >= DEFAULT_CAPACITY &&
+ capacity <= MAX_BUFFER_CAPACITY_UPPER_BOUND,
+ "Max buffer capacity must be in range [%s, %s], " +
+ "but got %s",
+ DEFAULT_CAPACITY, MAX_BUFFER_CAPACITY_UPPER_BOUND,
+ capacity);
+
+ if (!explicit) {
Review Comment:
‼️ **Freeze the process-wide cap before any graph can use it**
Evidence: `StandardHugeGraph` now passes `explicit=false` when a graph omits
`serializer.buffer_max_capacity`, and `BytesBuffer.initMaxBufferCapacity()`
returns without setting `maxBufferCapacity`. If that default-config graph is
already open, a later graph with an explicit value can still set the static
JVM-wide cap, so buffers created after that point for the first graph use the
later graph's limit instead of the default it started with.
Impact: the serializer limit for a running graph can change solely because
another graph is created later, leaving multi-graph behavior dependent on load
order.
Requested fix: select or freeze the single process-wide value before any
graph is opened, or reject late explicit initialization once any graph has
started using the default process value. Please add a regression test covering
a default graph that remains open while a later explicit graph is opened.
--
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]
