feat(serializer) : make buffer max capacity configurable#3049
feat(serializer) : make buffer max capacity configurable#3049LegendPei wants to merge 5 commits into
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3049 +/- ##
============================================
- Coverage 36.08% 1.56% -34.53%
+ Complexity 338 43 -295
============================================
Files 803 781 -22
Lines 68227 65748 -2479
Branches 8963 8520 -443
============================================
- Hits 24617 1026 -23591
- Misses 40963 64636 +23673
+ Partials 2647 86 -2561 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
imbajin
left a comment
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.
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.
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
left a comment
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]
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