Problem
Under sustained write load with large transaction bundles, Blaze can run out of memory on small heaps. The memory is held by the transaction requests themselves: every accepted transaction bundle is parsed into memory and its resources stay strongly reachable until the transaction is fully indexed, because the request only completes after d/transact returns. With many concurrent large bundles, the parsed bundles alone can approach the heap size.
Approaches that discard the local payload sent through the transaction log under memory pressure (a SoftReference, or a fixed in-flight memory budget) don't help: the payload aliases the resources already held by the pending request, so discarding it frees nothing. It only forces the resource indexer to load and parse a second copy of the resources from the resource store — increasing memory usage and GC pressure exactly when memory is scarce.
Solution
Introduce some form of server-side admission control for transaction requests: bound how many transaction requests are processed concurrently on a tight memory budget, so that requests beyond that bound are delayed or rejected before their bundles occupy the heap, instead of driving the JVM into GC thrashing or out-of-memory situations. The concrete mechanism is intentionally left open here.
Problem
Under sustained write load with large transaction bundles, Blaze can run out of memory on small heaps. The memory is held by the transaction requests themselves: every accepted transaction bundle is parsed into memory and its resources stay strongly reachable until the transaction is fully indexed, because the request only completes after
d/transactreturns. With many concurrent large bundles, the parsed bundles alone can approach the heap size.Approaches that discard the local payload sent through the transaction log under memory pressure (a
SoftReference, or a fixed in-flight memory budget) don't help: the payload aliases the resources already held by the pending request, so discarding it frees nothing. It only forces the resource indexer to load and parse a second copy of the resources from the resource store — increasing memory usage and GC pressure exactly when memory is scarce.Solution
Introduce some form of server-side admission control for transaction requests: bound how many transaction requests are processed concurrently on a tight memory budget, so that requests beyond that bound are delayed or rejected before their bundles occupy the heap, instead of driving the JVM into GC thrashing or out-of-memory situations. The concrete mechanism is intentionally left open here.