feat(serializer) : make buffer max capacity configurable#3049
Open
LegendPei wants to merge 6 commits into
Open
feat(serializer) : make buffer max capacity configurable#3049LegendPei wants to merge 6 commits into
LegendPei wants to merge 6 commits into
Conversation
dosubot
Bot
added
size:L
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3049 +/- ##
============================================
+ Coverage 36.08% 39.17% +3.09%
- Complexity 338 620 +282
============================================
Files 803 814 +11
Lines 68227 69414 +1187
Branches 8963 9165 +202
============================================
+ Hits 24617 27191 +2574
+ Misses 40963 39381 -1582
- Partials 2647 2842 +195 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
imbajin
reviewed
Jun 5, 2026
imbajin
left a comment
imbajin
left a comment
Member
There was a problem hiding this comment.
The implementation is close and the process-wide scope is the right fit for BytesBuffer. Please avoid last-opened-graph-wins behavior by making that process-wide semantic explicit and rejecting conflicting graph configs.
bitflicker64
added a commit
to bitflicker64/incubator-hugegraph
that referenced
this pull request
Jun 7, 2026
tail --pid does not forward signals to the supervised process. Add a TERM/INT trap that sends SIGTERM to Java and polls with kill -0 until Java exits cleanly before the entrypoint exits. Addresses review feedback from imbajin on apache#3049.
VGalaxies
reviewed
Jun 8, 2026
Contributor
There was a problem hiding this comment.
Review summary
- Blocking: yes
- Summary: The PR leaves graph lock groups registered when the new serializer buffer capacity initialization fails, which can block a corrected retry in the same process.
- Evidence:
- Static review
git diff --check origin/master...HEADpassed.mvn test -pl hugegraph-server/hugegraph-test -am -P unit-test -Dtest=BytesBufferTestfailed before reaching the target tests becausehugegraph-pdran surefire with no tests
…oups Move BytesBuffer.initMaxBufferCapacity() and other process-wide static config initializations before LockUtil.init() so that validation failures (e.g. invalid or conflicting serializer.buffer_max_capacity) cannot leave orphaned lock groups in LockManager, which would block subsequent graph load attempts without a process restart. 🤖 Generated with [Qoder][https://qoder.com]
imbajin
reviewed
Jun 8, 2026
imbajin
left a comment
imbajin
left a comment
Member
There was a problem hiding this comment.
Blocking: yes. Summary: The process-wide serializer buffer cap is still sourced from each graph config, so mixed custom/default graph configs can fail multi-graph startup. Evidence: static review of GraphManager local graph loading plus BytesBufferTest passed locally.
When the process-wide max buffer capacity is already initialized by one graph, treat the default config value (MAX_BUFFER_CAPACITY) from other graphs as "inherit" rather than a conflicting value. This prevents a single custom graph from blocking unrelated default-config graphs in a multi-graph server deployment. Add testMaxBufferCapacityInheritsProcessWideValue covering one custom graph plus one default graph coexistence. 🤖 Generated with [Qoder][https://qoder.com]
Add three tests covering previously uncovered code paths: - testResizeCappedAtMaxBufferCapacity: Math.min capping in require() when requiredCapacity + DEFAULT_CAPACITY exceeds maxCapacity - testSetMaxBufferCapacityAtUpperBound: upper boundary acceptance - testLZ4DecompressSucceedsWithCustomMaxBufferCapacity: decompress success path with a custom process-wide cap 🤖 Generated with [Qoder][https://qoder.com]
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose of the PR
This PR makes the max capacity of one serializer buffer configurable instead of always using the hardcoded default 128MB limit.
The default behavior remains unchanged, while users who need to serialize larger objects can tune the buffer limit through configuration. The new option is still bounded to avoid unbounded memory allocation.
Main Changes
Does this PR potentially affect the following parts?
Documentation Status
Doc - TODODoc - DoneDoc - No Need