Replies: 2 comments
-
@tttomat19 if you are not sure and wouldn't share any details beyond "too many" allocations, then why did you file this as a bug? |
Beta Was this translation helpful? Give feedback.
-
Changing that constant therefore can and will affect the throughput, in particular for the workloads that use multiple channels and high QoS prefetch values. @tttomat19 you are welcome to use a smaller value and report what do the benchmarks look like. Given that this is not a common complaint and the value used is similar to the prefetch value range that's considered to be optimal (going over 300-400 usually produces no throughput improvement), I doubt there will be a lot of interest in tweaking this value. Making it configurable via |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the bug
I can see a lot of allocations from
List<Runnable> block = new ArrayList<Runnable>(size);
MAX_RUNNABLE_BLOCK_SIZE
is 256 and not configurableCould it be smaller?
To be fair I'm not sure, just JMC shows allocations are right there.
Reproduction steps
about 4k messages per second input * about 1kb size each
Expected behavior
Less wasted allocations from here
Additional context
No response
Beta Was this translation helpful? Give feedback.
All reactions